.png)
Dropbox Integration Guide
Connect Dropbox files, folders, sharing data, and account changes with enterprise systems through REST APIs, OAuth 2.0, webhooks, and Martini workflows.
Dropbox integration options at a glance
Dropbox provides a versioned HTTP API v2 for files, folders, sharing, users, teams, metadata, and content operations. OAuth 2.0 uses app credentials, scopes, bearer access tokens, and refresh tokens. Dropbox also supports account-level webhook notifications, although applications must use stored cursors and files/list_folder/continue to retrieve the authoritative changes. File uploads, downloads, revisions, upload sessions, and selected asynchronous operations support document workflows. Martini can consume these APIs, receive webhook notifications through an exposed API, persist cursors, map metadata, process file content, and coordinate retries and downstream updates in workflows.
| Integration point | Supported by Dropbox? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Dropbox API v2 provides JSON RPC-style operations for files, folders, sharing, users, teams, authentication, metadata, and content management. | Martini can consume Dropbox HTTP endpoints, generate reusable API assets from definitions where applicable, map responses, and orchestrate multi-step workflows. |
| Webhooks / outbound callbacks | Yes | Dropbox sends account-level notifications when linked accounts may have changed; the notification does not contain the complete change set. | Martini can expose an API endpoint for the webhook, handle the verification challenge, validate requests, trigger synchronization, and retrieve changes using a stored cursor. |
| File / attachment APIs | Yes | Dropbox supports file upload, download, metadata, revisions, path-based content operations, and large-file upload sessions. | Martini workflows can transfer and validate content, map metadata, stage or process files, and use separate upload-session steps for large documents. |
| Bulk / async / batch APIs | Limited | Upload sessions and asynchronous operations are available for selected operations, but Dropbox does not provide a universal bulk API for every object. | Martini can model endpoint-specific asynchronous jobs, poll status where required, and use bounded retries and workflow state. |
| Authentication | Yes | Dropbox supports OAuth 2.0 authorization code flows, app keys and secrets, scopes, bearer access tokens, refresh tokens, and team permissions. | Martini can store secrets and refresh-token configuration securely, apply bearer authentication, and separate environment credentials from workflow logic. |
| Cursor-based synchronization | Yes | files/list_folder returns a cursor that can be persisted and supplied to files/list_folder/continue for incremental added, modified, and deleted entries. | Martini can persist cursors, process pages, coordinate webhook and scheduled triggers, and advance the cursor only after successful processing. |
| SDKs | Yes | Dropbox provides official SDKs for several programming languages, although direct HTTP API consumption is sufficient for most integration workflows. | Martini can consume the HTTP API directly and can use custom JVM-compatible logic only when a supported SDK or equivalent implementation is appropriate. |
| Database access | No | Dropbox does not expose general-purpose SQL database connectivity for application integrations. | Martini can use a separate supported SQL database for cursors, idempotency keys, and audit state, but not as a Dropbox access method. |
How Dropbox exposes data and business events
Dropbox REST APIs
Dropbox API v2 is the primary integration interface. It exposes JSON endpoints for files, folders, sharing, users, teams, metadata, content transfer, revisions, and selected asynchronous operations.
Martini implementation pattern
Martini consumes the relevant Dropbox HTTP endpoints from workflows or APIs, applies OAuth bearer authentication, maps responses into canonical models, and coordinates dependent calls such as metadata retrieval followed by content download.
Implementation sequence
Dropbox webhooks
Dropbox webhooks provide account-level notifications that linked accounts may have changed. They do not contain the complete file-change set and therefore must be combined with cursor-based listing.
Martini implementation pattern
Martini exposes a receiving API for Dropbox delivery, handles the verification challenge and request validation, then starts a synchronization workflow. The workflow uses the account or namespace cursor with files/list_folder/continue to retrieve authoritative changes.
Implementation sequence
Dropbox file content APIs
Dropbox supports file upload, download, metadata, revisions, and upload sessions for large files. Content operations are central to document publishing and ingestion workflows.
Martini implementation pattern
Martini stages or streams content where supported, validates size and type, and calls Dropbox content endpoints. Large uploads are divided into upload-session operations, while downloaded files can be parsed and transformed before delivery to another system.
Implementation sequence
Dropbox cursor synchronization
Dropbox folder synchronization uses files/list_folder to establish a cursor and files/list_folder/continue to retrieve subsequent changes. Results can include added, modified, and deleted entries.
Martini implementation pattern
Martini combines scheduled and webhook-triggered workflows, persists one or more cursors in secure integration state, processes all returned pages, and commits cursor advancement only after successful downstream handling.
Implementation sequence
Common Dropbox integration patterns
Pattern 1: Synchronize Dropbox documents to a business system
When to use this pattern
Use this pattern when a business application needs an indexed or synchronized view of Dropbox files and folders. A webhook can prompt synchronization, while the cursor remains the source of the actual change set.
Integration direction
Example Mapping
| Dropbox Field | Canonical Field | Target Field |
|---|---|---|
| name | documentName | file_name |
| path_display | documentPath | repository_path |
| id | sourceFileId | external_id |
| content_hash | contentHash | checksum |
Martini implementation pattern
Martini receives a Dropbox notification or scheduled trigger, loads the namespace cursor, retrieves changed entries, filters relevant paths, downloads content when needed, maps metadata, and writes the result to the target system. It uses identifiers, revisions, and hashes for idempotency and advances the cursor only after successful processing.
Martini capabilities used
- workflows
- API consumption
- webhook receiving
- data mapping
- business rules
- error handling
Pattern 2: Publish enterprise documents to Dropbox
When to use this pattern
Use this pattern when documents created in Salesforce, ServiceNow, or another application must be stored in a governed Dropbox path and optionally shared through a Dropbox link.
Integration direction
Example Mapping
| Dropbox Field | Canonical Field | Target Field |
|---|---|---|
| attachment.content | fileContent | file_binary |
| attachment.name | fileName | path |
| case.number | businessReference | custom_metadata_or_audit_state |
| documentType | contentClassification | destination_folder |
Martini implementation pattern
A Martini workflow receives document content and business metadata, determines the namespace and path, creates missing folders where allowed, and uploads the file. For large content it uses upload sessions, applies overwrite or conflict rules, and returns the Dropbox identifier, revision, path, or shared link to the source application.
Martini capabilities used
- API consumption
- workflow orchestration
- file handling
- data mapping
- business rules
- retry handling
Pattern 3: Ingest and transform Dropbox files
When to use this pattern
Use this pattern when files placed in a designated Dropbox folder are inputs for document processing, data loading, or business automation.
Integration direction
Example Mapping
| Dropbox Field | Canonical Field | Target Field |
|---|---|---|
| path_lower | sourcePath | source_document_path |
| client_modified | sourceModifiedAt | received_at |
| content_hash | sourceChecksum | external_checksum |
| file content | parsedPayload | business_fields |
Martini implementation pattern
Martini retrieves changed entries, filters by path and supported type, downloads content, parses or validates the payload, maps it to Salesforce fields, and applies business rules before writing. It records the source file identifier and revision so duplicate notifications or repeated cursor processing do not create duplicate business results.
Martini capabilities used
- workflows
- file processing
- JSON and XML handling
- data mapping
- validation
- error handling
Pattern 4: Synchronize Dropbox Business team members
When to use this pattern
Use this pattern when authorized Dropbox Business team information must be compared with an identity, HR, or service-management platform.
Integration direction
Example Mapping
| Dropbox Field | Canonical Field | Target Field |
|---|---|---|
| team_member_id | externalUserId | source_user_id |
| profile.email | ||
| profile.name.display_name | displayName | name |
| status | accountStatus | active |
Martini implementation pattern
A scheduled Martini workflow calls the authorized Dropbox team endpoints, maps member identifiers and status, compares them with the target system, and applies only approved changes. Missing permissions, revoked authorization, and user conflicts are routed for review instead of being retried indefinitely.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- business rules
- secure configuration
- error handling
Applications commonly integrated with Dropbox
Dropbox can be integrated with named business applications when documents, links, metadata, or team-member information must move between collaboration and enterprise processes. These relationships are architecture patterns rather than evidence of a dedicated Dropbox or Martini connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Store or retrieve customer, account, opportunity, and case documents alongside Salesforce records. | Salesforce → Martini → Dropbox | A Martini workflow receives Salesforce metadata and document content, resolves a Dropbox namespace and path, creates folders when needed, uploads the file, and returns the Dropbox path, identifier, revision, or shared-link information to Salesforce. |
| ServiceNow | Publish runbooks, incident evidence, change documents, or knowledge-source files to Dropbox and return Dropbox links or content to ServiceNow processes. | ServiceNow → Martini → Dropbox | Martini orchestrates ServiceNow API calls with Dropbox metadata and content endpoints, applies path and file-type rules, uses upload sessions for large files, and records processing status and errors. |
| Microsoft SharePoint | Support document migration, coexistence, or rationalization between Dropbox and SharePoint repositories. | Dropbox → Martini → Microsoft SharePoint | A scheduled or webhook-triggered workflow reads Dropbox changes with cursors, downloads required content, maps metadata and paths, writes files to SharePoint, and advances the cursor only after successful processing. |
| DocuSign | Send Dropbox-stored contracts for signature and archive completed documents back in Dropbox. | Dropbox → Martini → DocuSign | Martini retrieves the file and metadata from Dropbox, submits the document to DocuSign, tracks the signature result through the available application interface, and stores the executed document and status in Dropbox. |
| Slack | Publish notifications or links when Dropbox files are added, changed, or shared. | Dropbox → Martini → Slack | Martini receives a Dropbox account-change notification, retrieves the changed entries using the stored cursor, filters relevant paths or revisions, and posts a controlled message containing the Dropbox link or processing result. |
How to build a Dropbox integration in Martini
Objective
Establish Dropbox OAuth 2.0 access with the scopes and team permissions required by the integration.
Instructions in Martini
- Register the Dropbox application and record its app key and secret
- Configure authorization-code or appropriate OAuth settings
- Store refresh tokens, secrets, and environment-specific values securely
- Use the narrowest practical Dropbox scopes
Objective
Select webhook, scheduled, or API-driven initiation according to the synchronization and publishing requirement.
Instructions in Martini
- Expose a Martini API for Dropbox webhook delivery when event-driven synchronization is appropriate
- Implement the Dropbox verification challenge and request validation
- Use a scheduler for reconciliation or cursor recovery
- Use an API trigger for on-demand document publishing
Objective
Retrieve authoritative Dropbox metadata or content using API v2, cursors, and content endpoints.
Instructions in Martini
- Call files/list_folder to establish initial state
- Call files/list_folder/continue with the stored cursor for incremental changes
- Retrieve file metadata or content only when required
- Use upload sessions for large files and handle asynchronous operations where documented
Objective
Coordinate Dropbox calls, downstream applications, persistence, and workflow state in a maintainable Martini workflow.
Instructions in Martini
- Separate fast webhook receipt from longer synchronization work when appropriate
- Persist cursors, revisions, hashes, and idempotency keys
- Route files, folders, and deleted entries through explicit business branches
- Use reusable services or workflows for shared Dropbox operations
Objective
Transform Dropbox metadata and file content into the canonical model required by downstream systems.
Instructions in Martini
- Map identifiers, paths, namespaces, revisions, hashes, and timestamps
- Validate file type, size, required metadata, and parsed content
- Apply path, naming, sharing, and conflict rules
- Preserve source identifiers for auditability
Objective
Deliver transformed documents, links, metadata, or team information to target applications and persist successful integration state.
Instructions in Martini
- Create or update target objects using the mapped model
- Return Dropbox paths, identifiers, revisions, or shared links when publishing
- Advance a cursor only after all required downstream actions succeed
- Record business and technical outcomes
Common Dropbox data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Files | Represent file metadata, content, paths, hashes, revisions, uploads, and downloads. | Salesforce, ServiceNow, SharePoint, DocuSign, Google Drive | Martini maps metadata, downloads or uploads content, validates file characteristics, and preserves identifiers, revisions, and processing status. |
| Folders | Represent hierarchical Dropbox locations and support folder creation and listing. | SharePoint, Salesforce, ServiceNow, Google Drive | Workflows resolve namespaces and paths, create missing folders where permitted, and apply conflict and naming rules. |
| File and folder entries | Represent entries returned by listing operations, including files, folders, and deleted items. | Document indexes, databases, SharePoint, Slack | Martini processes paginated cursor results, distinguishes deleted entries, applies filters, and persists synchronization state. |
| Shared links | Provide access links for files or folders and support creation, listing, updating, and revocation. | Salesforce, ServiceNow, Slack, DocuSign | Martini applies sharing policies, maps links to business records, and records link lifecycle results. |
| Users | Provide current-user and account lookup information for identity and ownership workflows. | Identity platforms, HR systems, ITSM platforms | Martini maps Dropbox account identifiers and attributes to approved target models while respecting OAuth scopes. |
| Team members | Support Dropbox Business user and access synchronization through team endpoints. | Identity governance, HR systems, ServiceNow | Martini retrieves authorized team data, compares identifiers and status, applies target-side rules, and records permission failures. |
Authentication and security considerations
OAuth 2.0 and scopes
Dropbox uses OAuth 2.0 with app keys, app secrets, scoped access tokens, and refresh tokens. Team and administrator operations require appropriate permissions and scopes.
Secure configuration
Martini should keep Dropbox app secrets, refresh tokens, and environment-specific configuration in secure configuration or secrets management rather than embedding credentials in workflows.
Least privilege
- Request only the Dropbox scopes required by the integration.
- Separate individual-user access from Dropbox Business team access where appropriate.
- Protect webhook endpoints and validate Dropbox delivery according to Dropbox guidance.
Operational considerations for Dropbox integrations
Cursors and pagination
Persist Dropbox cursors securely and advance them only after the corresponding changes have been processed successfully. Handle cursor invalidation with a controlled full or scoped listing.
Throttling and retries
Use bounded retries and backoff for throttling and temporary service failures. Do not repeatedly poll when webhook notifications and cursors can reduce unnecessary requests.
Files and idempotency
- Use upload sessions for large files and avoid unnecessary in-memory buffering.
- Use file identifiers, revisions, hashes, and processing keys rather than names alone.
- Define explicit overwrite, autorename, or conflict behavior for destination paths.
- Test deleted entries, shared folders, namespaces, representative file types, and team permissions.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond scripts
Martini provides workflows and APIs for combining Dropbox calls, webhook receipt, scheduled reconciliation, file processing, downstream applications, and integration-side state without creating isolated scripts for every use case.
Maintainable transformation
Mappings, validation, business rules, reusable services, and environment-secured configuration keep Dropbox integrations easier to change as paths, target models, permissions, and document requirements evolve.
Operational control
- Coordinate cursor commits with successful downstream processing.
- Apply consistent error handling, retry, and idempotency behavior.
- Expose controlled APIs for publishing documents or receiving notifications.
- Centralize monitoring and troubleshooting for multi-system workflows.
Frequently asked questions
Dropbox can be integrated through its versioned HTTP API v2, OAuth 2.0 authentication, file and folder content endpoints, cursor-based synchronization, and account-level webhook notifications. Enterprise workflows typically retrieve changes with files/list_folder/continue, transfer content, map metadata, and write results to business applications.
Yes. Martini can consume Dropbox REST APIs, receive Dropbox webhook notifications through an exposed API, manage OAuth-secured calls, process files, persist cursors, and orchestrate synchronization with other enterprise systems. A dedicated native Martini Dropbox connector is not confirmed in the supplied documentation.
No. A dedicated Dropbox connector is not required. Martini can use Dropbox's confirmed native integration mechanisms, including REST API v2, OAuth 2.0, file-content endpoints, cursor-based listing, upload sessions, and webhook notifications.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Dropbox. The integration is subject to the provisioned capacity of the Martini environment. Separate Dropbox subscription or usage charges, infrastructure costs, and other third-party costs may apply.
Dropbox API v2 is the primary method for files, folders, sharing, users, teams, metadata, and content. Use OAuth 2.0 for authorization, webhooks as change signals, cursors for authoritative incremental synchronization, and upload sessions for large files. Dropbox GraphQL and SOAP APIs are not confirmed.
Dropbox supports account-level webhook notifications indicating that one or more linked accounts may have changed. They are not complete per-file events, so Martini must use a stored cursor with files/list_folder/continue to retrieve added, modified, or deleted entries and should handle duplicate or concurrent notifications.
An initial files/list_folder call establishes a cursor. Subsequent workflows use files/list_folder/continue, often after a webhook or scheduled trigger, and persist the cursor after successful processing. Martini maps paths, identifiers, namespaces, revisions, hashes, timestamps, and file content into a canonical model before applying target-specific rules.
Workflows should distinguish transient throttling or service failures from authorization, scope, path, validation, and conflict errors. Martini can apply bounded retries and backoff for transient conditions, while identifiers, revisions, content hashes, cursors, and idempotency keys prevent duplicate downstream processing. Invalid cursors should trigger a controlled resynchronization path.
Related Martini documentation
Workflows
Build a reliable Dropbox integration with Martini
Use Martini to connect Dropbox APIs and webhook notifications with enterprise applications through secure workflows, reusable mappings, controlled APIs, and operationally manageable synchronization.