Intégration API Dropbox
Nous développons votre connecteur Dropbox
Nous branchons Dropbox à votre dossier métier : un PDF ajouté ouvre la mission, les livrables partent en lien de partage, sans lien magique collé dans un champ.
- Équipe produit senior
- connecteurs fichiers en production
- du cadrage au monitoring
À quoi sert l'API Dropbox et pourquoi connecter Dropbox à son application métier ?
Dropbox est un outil de partage de fichiers très utilisé par les prestataires, agences et équipes distribuées qui ne veulent pas migrer vers SharePoint. Son API permet à votre application de déposer ou récupérer des fichiers dans un dossier Dropbox, de détecter l'ajout d'un document et de déclencher un traitement automatique. On l'intègre quand vos clients ou partenaires partagent leurs fichiers via Dropbox et que vous voulez les importer automatiquement dans votre logiciel : sans demander un changement d'outil à l'utilisateur et sans surveillance manuelle du dossier.
Ce que nos clients construisent sur l'API Dropbox
Dossier client qui crée la tâche
Un PDF ajouté au dossier ouvre la mission. Espace dédié à l'app ou dossier choisi, pas un lien magique collé dans un champ.
Export de livrables vers App Folder
Liens de partage via l'API sharing vivante. Pas sharing/get_shared_links, retiré en octobre 2026.
Bascule de GED par finish_batch
Des milliers de fichiers, un finish_batch par namespace. Les /files/upload parallèles prennent le verrou too_many_write_operations.
Bouton Joindre via le Chooser
Pour un formulaire métier, le sélecteur Dropbox suffit souvent. Moins lourd à auditer qu'un accès Full Dropbox.
Ce que ça change dans vos fichiers Dropbox
La technique au service d'un résultat mesurable : un dossier qui alimente le métier, des uploads qui passent, des liens encore valides.
Le lien collé n'est plus le connecteur
Le binaire reste chez Dropbox, les métadonnées dans votre dossier. Un lien copié qui expire cesse de casser le parcours.
Un accès borné est un argument RGPD
L'app ne voit que son espace. Le consentement est lisible, la revue de sécurité passe mieux qu'un accès large à tout le compte.
La migration ne se verrouille pas
Les gros transferts sont cadencés proprement. On évite le blocage « trop d'écritures » qui tue un import parallèle naïf.
Les liens de partage restent valides
On utilise les routes de partage actuelles, pas des APIs en fin de vie. Vous ne découvrez pas la coupure le jour J.
Comment nous livrons votre connecteur Dropbox
Cadrage
App Folder ou Full Dropbox (figé à la création), Chooser ou OAuth, équipe ou compte. On ne part pas d'un Full Dropbox « au cas où ».
Développement
Challenge GET, HMAC hex, lease par dbid, curseur atomique après succès, upload session dès 150 Mo, finish_batch par namespace.
Recette
Handler synchrone qui dépasse 10 s, 35 erreurs / 10 min, too_many_write_operations, curseur reset, Paper legacy. Rejeu avant bascule.
Monitoring
Taux d'échec webhook avant 35/10 min et 4,5 %. Procédure écrite de réactivation console. Alerte Retry-After, distinction des deux 429.
Ce que permet l'API Dropbox
- list_folder et curseur
- POST /2/files/list_folder puis continue. Ajouts, modifications, suppressions, partages. content_hash, rev, server_modified pour ne pas retélécharger.
- Webhooks compte, pas fichier
- POST JSON de dbid. Scope files.metadata.read autorisé, sinon silence. Challenge GET, nosniff. HMAC X-Dropbox-Signature, secret d'app côté serveur.
- Upload simple et sessions
- /2/files/upload sous 150 Mo. Au-delà : start, append_v2, finish / finish_batch (jusqu'à 1 000, async_job_id). session_type concurrent, chunks 4 Mo.
- Équipe et sharing vivant
- Dropbox-API-Select-User par membre, limites user endpoints par membre. Liens via l'API sharing actuelle. get_shared_links : retrait octobre 2026.
Le vocabulaire de l'API Dropbox
- cursor
- État de list_folder, persisté par compte et par namespace. Invalidé (reset) : recrawl. Le persister avant traitement, c'est perdre des pages en cas de crash.
- dbid
- Identifiant de compte dans le POST webhook (list_folder.accounts). Plusieurs utilisateurs par POST, plusieurs POST par utilisateur. Lease par dbid si l'action n'est pas idempotente.
- X-Dropbox-Signature
- HMAC-SHA256 hex du corps brut, secret d'application. Se vérifie côté serveur : un SPA qui embarque l'app secret a déjà perdu. compare_digest, pas ==.
- too_many_write_operations
- Verrou de namespace (racine, dossier partagé, team folder), pas un quota. Retry-After parfois à 0. Parade : batch d'upload sessions, un finish_batch par namespace.
- App Folder
- Portée figée à la création : /Apps/... dédié. Full Dropbox lit le compte. Trop étroit, vous ne lisez pas le dossier client existant ; trop large, la revue d'app s'alourdit.
- get_shared_links
- Route sharing dépréciée, retrait octobre 2026. Ne pas persister ces liens. Utiliser l'API sharing actuelle pour créer. Chantier daté, du même ordre qu'EWS côté Microsoft.
Les contraintes réelles de l'API Dropbox
Dix secondes, puis désactivation
Le POST webhook a 10 s. Plus de 35 erreurs / 10 min et un taux d'échec > 4,5 % : désactivation automatique, plus un courriel. Un handler qui appelle list_folder/continue dans la requête se fait couper, puis tuer.
Deux 429 différents
too_many_requests (quota par autorisation) et too_many_write_operations (verrou). Les 429 comptent dans le quota. Dropbox ne publie pas les plafonds : on dimensionne sur Retry-After et les batch endpoints.
Pas de filtre d'événements
Toute modification du compte notifie. Extension, dossier, suppression : après continue. Le premier crawl d'un compte plein est le pic de charge.
PKCE et jetons courts, 2026
Les jetons longs sont dépréciés. Implicit grant à désactiver dans la console. Team token ≠ user token : Select-User par membre, pas un mega-compte de service.
API Dropbox ou API SharePoint ?
Deux espaces de fichiers. Le bon dépend du réflexe déjà là (dossier envoyé vs locataire Microsoft).
| Critère | DropboxCette page | Microsoft 365Graph fichiers |
|---|---|---|
| Parc typique | Indépendants, agences, bureaux d'études | SharePoint / OneDrive du locataire |
| Périmètre fin | App Folder, figé à la création | Sites.Selected + POST /permissions |
| Webhook | Liste de dbid, curseur ensuite | Signal Graph, delta ensuite |
| Signature | HMAC hex, secret d'app | Abonnement Graph, 202 d'abord |
| Gros volumes | finish_batch, verrou de namespace | Unités SharePoint, session 320 Kio |
| Dette datée | get_shared_links, octobre 2026 | CSOM/REST vers Graph, EWS hors fichiers |
| Le bon cas | Le flux est déjà un dossier Dropbox | L'entreprise est déjà sur Microsoft 365 |
Google Drive se discute sur un parc Workspace. Box quand la GED est déjà gouvernée hors des suites bureautiques. Chooser Dropbox sans OAuth reste un produit à part.
Ce que nous mesurons sur une intégration Dropbox
Les autres API de fichiers
Si Dropbox n'est pas l'espace déjà là, ces options se discutent au cadrage.
DropboxNous développons votre connecteur DropboxCette page
Microsoft 365SharePoint et OneDrive via Graph, Sites.Selected.
Google DriveDrive Workspace, Picker, export Docs/Sheets.
BoxGED entreprise, webhooks HMAC, App Users.On combine Dropbox avec
La stack qui entoure Dropbox sur nos projets.
Intégration Dropbox : vos questions
App Folder ou Full Dropbox à la création, OAuth avec refresh (jetons courts), endpoint GET de challenge et POST signé (X-Dropbox-Signature hex, secret serveur), réponse 200 en moins de 10 s, worker avec lease par dbid, curseur list_folder/continue persisté après succès. Upload : 150 Mo, puis sessions et finish_batch par namespace. La partie sensible n'est pas le premier upload, c'est un webhook synchrone qui se fait désactiver, et get_shared_links encore collé dans le code.
Un premier flux utile, typiquement App Folder plus webhook vers une tâche métier, se livre en deux à trois semaines. Une bascule de GED (finish_batch, Select-User, sharing vivant) demande plutôt six à huit semaines. Le Chooser sans OAuth est plus court si le besoin est seulement « joindre un fichier ». Nous cadrons la portée de contenu avant, parce qu'on ne la change pas après création de l'app. C'est un arbitrage de cadrage, écrit avant le premier appel, pas une surprise de recette.
App Folder si l'app peut vivre dans /Apps/... : consentement lisible, revue plus simple, argument RGPD. Full Dropbox si vous devez lire un dossier client déjà là. La décision est antérieure au code. Full Dropbox plus scopes larges alourdit la revue. Trop étroit, le cas d'usage casse. Team : jeton d'équipe plus Select-User par membre, pas un compte de service unique. C'est un arbitrage de cadrage, écrit avant le premier appel, pas une surprise de recette.
On suit le réflexe déjà là. Dropbox : dossier envoyé, App Folder, curseur list_folder. Drive : parc Workspace, Picker, export Docs. SharePoint si le locataire Microsoft est le disque. Box si une GED entreprise est déjà gouvernée. Les quatre ont un incrément et un push ; seul Box envoie le détail dans le webhook, Dropbox et Drive envoient un signal. C'est un arbitrage de cadrage, écrit avant le premier appel, pas une surprise de recette.
La route sharing/get_shared_links a un avis de dépréciation et un retrait en octobre 2026 (spécification officielle Dropbox). Ne plus la lire, ne plus persister ses URL. Créer les liens avec l'API sharing actuelle, stocker l'identifiant de lien vivant, prévoir un job de migration des liens déjà servis. C'est un chantier daté, du même ordre que la coupure EWS côté Microsoft : on le met dans le cadrage, pas dans un ticket de novembre 2026.
Un projet d'intégration Dropbox ?
Parlons-en. 30 minutes pour cadrer App Folder, webhooks, finish_batch, et le remplacement de get_shared_links avant octobre 2026.
Parler de mon projet Dropbox