API integration for Dropbox
We build your Dropbox connector
We wire Dropbox into your business file: a PDF added opens the job, deliverables leave as sharing links, without a magic link pasted in a field.
- Senior product team
- file connectors in production
- from scoping to monitoring
What does the Dropbox API provide and why connect Dropbox to a business application?
Dropbox is a widely used file-sharing tool among service providers, agencies and distributed teams that do not want to migrate to SharePoint. Its API lets your application deposit or retrieve files from a Dropbox folder, detect when a document is added and trigger an automated process. You integrate it when your clients or partners share files via Dropbox and you want to import them automatically into your software: without asking the user to change tools and without manually monitoring the folder.
What our clients build on the Dropbox API
Client folder that creates the task
Webhook plus cursor: a PDF added opens the job. App Folder or a dedicated folder, not a magic link pasted in a field.
Deliverable export into App Folder
Sharing links via the live sharing API. Not sharing/get_shared_links, retired in October 2026.
DMS cutover via finish_batch
Thousands of files, one finish_batch per namespace. Parallel /files/upload takes the too_many_write_operations lock.
Attach button via the Chooser
No OAuth, for a business form. Often the right product, cheaper to audit than Full Dropbox.
What this changes in your Dropbox files
Engineering in service of a measurable outcome: a folder that feeds the business, uploads that pass, links that stay valid.
The pasted link is no longer the connector
The binary stays in Dropbox, metadata in your record. An expired copied link stops breaking the journey.
Scoped access is a GDPR argument
The app only sees its space. Consent is readable; security review passes better than broad access to the whole account.
Migration does not lock up
Large transfers are paced properly. We avoid the too-many-writes lock that kills a naive parallel import.
Sharing links stay valid
We use current sharing routes, not end-of-life APIs. You do not discover the cut-over on day one.
How we deliver your Dropbox connector
Scoping
App Folder or Full Dropbox (frozen at creation), Chooser or OAuth, team or account. We do not start from Full Dropbox "just in case".
Development
GET challenge, hex HMAC, lease per dbid, atomic cursor after success, upload session from 150 MB, finish_batch per namespace.
Acceptance
Synchronous handler over 10 s, 35 errors / 10 min, too_many_write_operations, cursor reset, legacy Paper. Replay before cutover.
Monitoring
Webhook failure rate before 35/10 min and 4.5%. Written console reactivation procedure. Retry-After alert, distinction of the two 429s.
What the Dropbox API allows
- list_folder and cursor
- POST /2/files/list_folder then continue. Adds, edits, deletes, shares. content_hash, rev, server_modified so you do not re-download.
- Account webhooks, not file webhooks
- JSON POST of dbids. files.metadata.read must have been granted, otherwise silence. GET challenge, nosniff. HMAC X-Dropbox-Signature, app secret on the server.
- Simple upload and sessions
- /2/files/upload under 150 MB. Beyond: start, append_v2, finish / finish_batch (up to 1,000, async_job_id). concurrent session_type, 4 MB chunks.
- Team and live sharing
- Dropbox-API-Select-User per member, user-endpoint limits per member. Links via the current sharing API. get_shared_links: retirement October 2026.
Dropbox API vocabulary
- cursor
- list_folder state, persisted per account and per namespace. Invalidated (reset): recrawl. Persisting it before processing loses pages on a crash.
- dbid
- Account id in the webhook POST (list_folder.accounts). Several users per POST, several POSTs per user. Lease per dbid if the action is not idempotent.
- X-Dropbox-Signature
- HMAC-SHA256 hex of the raw body, application secret. Verified on the server: a SPA that embeds the app secret has already lost. compare_digest, not ==.
- too_many_write_operations
- Namespace lock (root, shared folder, team folder), not a quota. Retry-After sometimes 0. Workaround: batch of upload sessions, one finish_batch per namespace.
- App Folder
- Access frozen at creation: dedicated /Apps/.... Full Dropbox reads the account. Too narrow, you cannot read an existing client folder; too wide, app review gets heavier.
- get_shared_links
- Deprecated sharing route, retirement October 2026. Do not persist those links. Use the current sharing API to create. A dated project, of the same order as EWS on the Microsoft side.
The real constraints of the Dropbox API
Ten seconds, then disablement
The webhook POST has 10 s. More than 35 errors / 10 min and a failure rate > 4.5%: automatic disablement, plus an email. A handler that calls list_folder/continue in the request gets cut, then killed.
Two different 429s
too_many_requests (quota per authorisation) and too_many_write_operations (lock). 429s count toward the quota. Dropbox does not publish ceilings: we size on Retry-After and batch endpoints.
No event filter
Any account change notifies. Extension, folder, delete: after continue. The first crawl of a full account is the load peak.
PKCE and short-lived tokens, 2026
Long-lived tokens are deprecated. Implicit grant should be disabled in the console. Team token is not a user token: Select-User per member, not a mega service account.
Dropbox API or SharePoint API?
Two file spaces. The right one follows the reflex already there (sent folder vs Microsoft tenant).
| Criterion | DropboxThis page | Microsoft 365Graph files |
|---|---|---|
| Typical estate | Freelancers, agencies, engineering offices | SharePoint / OneDrive on the tenant |
| Fine perimeter | App Folder, frozen at creation | Sites.Selected + POST /permissions |
| Webhook | List of dbids, cursor afterwards | Graph signal, delta afterwards |
| Signature | HMAC hex, app secret | Graph subscription, 202 first |
| Large volumes | finish_batch, namespace lock | SharePoint units, 320 KiB session |
| Dated debt | get_shared_links, October 2026 | CSOM/REST to Graph, EWS outside files |
| The right case | The flow is already a Dropbox folder | The company is already on Microsoft 365 |
Google Drive comes up on a Workspace estate. Box when the DMS is already governed outside the office suites. The Dropbox Chooser without OAuth remains a separate product.
What we measure on a Dropbox integration
The other file APIs
If Dropbox is not the space already there, these options belong in the scoping conversation.
DropboxWe build your Dropbox connectorThis page
Microsoft 365SharePoint and OneDrive via Graph, Sites.Selected.
Google DriveWorkspace Drive, Picker, Docs/Sheets export.
BoxEnterprise DMS, HMAC webhooks, App Users.We combine Dropbox with
The stack around Dropbox on our projects.
Dropbox integration: your questions
App Folder or Full Dropbox at creation, OAuth with refresh (short-lived tokens), GET challenge endpoint and signed POST (X-Dropbox-Signature hex, server secret), 200 in under 10 s, worker with a lease per dbid, list_folder/continue cursor persisted after success. Upload: 150 MB, then sessions and finish_batch per namespace. The hard part is not the first upload, it is a synchronous webhook that gets disabled, and get_shared_links still pasted in the code.
A first useful flow, typically App Folder plus webhook into a business task, ships in two to three weeks. A DMS cutover (finish_batch, Select-User, live sharing) is closer to six to eight weeks. The Chooser without OAuth is shorter if the need is only "attach a file". We scope content access first, because you cannot change it after app creation. This is a scoping call, written down before the first request, not an acceptance surprise.
App Folder if the app can live in /Apps/...: readable consent, simpler review, GDPR argument. Full Dropbox if you must read a client folder already there. The decision is before the code. Full Dropbox plus wide scopes heavy the review. Too narrow, the use case breaks. Team: team token plus Select-User per member, not a single service account. This is a scoping call, written down before the first request, not an acceptance surprise.
Follow the reflex already there. Dropbox: sent folder, App Folder, list_folder cursor. Drive: Workspace estate, Picker, Docs export. SharePoint if the Microsoft tenant is the disk. Box if an enterprise DMS is already governed. All four have an increment and a push; only Box sends the detail in the webhook, Dropbox and Drive send a signal. This is a scoping call, written down before the first request, not an acceptance surprise.
The sharing/get_shared_links route has a deprecation notice and a retirement in October 2026 (official Dropbox specification). Stop reading it, stop persisting its URLs. Create links with the current sharing API, store the live link id, plan a migration job for links already served. This is a dated project, of the same order as the EWS cut on the Microsoft side: it goes in the scoping, not in a November 2026 ticket.
A Dropbox integration project?
Let's talk. 30 minutes to scope App Folder, webhooks, finish_batch, and replacing get_shared_links before October 2026.
Discuss my Dropbox project