Manuel utilisateur
Centre d'aide/Manuel utilisateur/Connecter Uber Direct : coter, expédier et suivre les livraisons locales

Connecter Uber Direct : coter, expédier et suivre les livraisons locales

Dernière mise à jour 2026-11-01

Copiez Client ID et Client Secret de votre app sur direct.uber.com → Developer → API credentials, copiez le Customer ID séparé depuis la page Developer, saisissez l’adresse d’enlèvement comme une chaîne JSON dans Integration, testez l’échange de jeton, puis demandez des livraisons Uber Direct.

Le connecteur Uber Direct demande des livraisons locales Uber Direct depuis ce système : il obtient un devis de livraison, crée une livraison à partir de ce devis, consulte le statut et peut annuler une livraison. C’est uniquement une connexion de livraison du dernier kilomètre : il n’importe pas les commandes du marketplace Uber Eats dans ce système et ne synchronise ni menus ni catalogues de magasin. Devis et livraisons utilisent votre propre compte client Uber Direct et votre adresse d’enlèvement.

Étapes Uber Direct : d’abord les identifiants de l’app et le Customer ID séparé, l’adresse d’enlèvement en JSON, puis le test de jeton.

Prérequis#

  • Un compte Uber Direct et l’accès à direct.uber.com → Developer, où se trouvent votre app et ses identifiants API.
  • Vous pouvez ouvrir votre app sur direct.uber.com → Developer → votre app → API credentials, où s’affichent le Client ID et le Client Secret. Le Client Secret ne s’affiche qu’une seule fois : prévoyez de le copier dans la connexion tout de suite et de le conserver en lieu sûr.
  • Vous avez aussi le Customer ID séparé, depuis direct.uber.com → Developer → Customer ID. C’est une valeur différente du Client ID : la connexion utilise les deux, pour des choses différentes.
  • Vous connaissez l’adresse d’enlèvement de votre magasin ou entrepôt par éléments (rue, ville, État, code postal et pays), car la connexion la prend comme une seule chaîne JSON, pas comme des champs séparés.

Obtenir les identifiants#

  1. Allez sur direct.uber.com → Developer → votre app → API credentials.
  2. Copiez le Client ID affiché sur cette page API credentials.
  3. Copiez le Client Secret affiché sur la même page API credentials. Il ne s’affiche qu’une seule fois : copiez-le maintenant, en entier, et conservez-le en lieu sûr. La connexion échange cette paire, Client ID plus Client Secret, contre un jeton d’accès, avec le scope eats.deliveries.
  4. Séparément, allez sur direct.uber.com → Developer → Customer ID et copiez le Customer ID. Ne le confondez pas avec le Client ID de la page de l’app : le Customer ID désigne votre compte client Uber Direct, et les demandes de livraison sont faites sous ce compte — le chemin de l’API le porte lui-même : /v1/customers/{customer_id}/deliveries.
Trois ID, deux endroits : Client ID et Client Secret vivent ensemble sur la page API credentials de votre app, tandis que le Customer ID vit séparément sur la page Developer. Si une demande de livraison échoue juste après un test réussi, la première chose à vérifier est un Customer ID placé dans un champ Client ID.

Remplir dans Integration#

  1. Ouvrez Integration → Marketplace → Uber Direct → Nouvelle connexion.
  2. client_id, obligatoire, Client ID : collez le Client ID de direct.uber.com → Developer → votre app → API credentials.
  3. client_secret, obligatoire, Client Secret : collez en entier le Client Secret de la même page API credentials. C’est un champ de type mot de passe, conservé comme secret. Souvenez-vous qu’il ne s’est affiché qu’une fois : travaillez depuis la copie conservée, pas de mémoire.
  4. customer_id, obligatoire, Customer ID : collez le Customer ID de direct.uber.com → Developer → Customer ID. Ce n’est pas le Client ID : les livraisons sont demandées sous ce compte client.
  5. pickup_address, obligatoire, adresse d’enlèvement (JSON) : saisissez l’adresse d’enlèvement comme UNE chaîne JSON, exactement sous cette forme : {"street_address":["20 W 34th St"],"city":"New York","state":"NY","zip_code":"10001","country":"US"}, avec les valeurs de votre propre magasin ou entrepôt à la place des valeurs d’exemple. Notez que street_address est un tableau entre crochets, et que tous les guillemets doivent être des guillemets droits anglais. Cette adresse est obligatoire pour passer des livraisons ; le test de connexion n’en a pas besoin.
  6. pickup_name, facultatif, nom d’enlèvement : le nom affiché pour l’enlèvement, par ex. Merchant ou le nom de votre magasin. pickup_phone_number, facultatif, téléphone d’enlèvement : un numéro qui joint le point d’enlèvement, par ex. +15551234567.

Tester la connexion#

Cliquez sur Tester la connexion. Ce test est l’échange de jeton lui-même : la connexion envoie vos client_id et client_secret au service d’accès d’Uber (type d’octroi client_credentials, scope eats.deliveries) et recevoir un jeton d’accès compte comme une réussite. Échanger un jeton n’a aucun effet secondaire — il ne crée aucune livraison et ne change rien — c’est pourquoi il peut servir de test. Si la réponse revient sans jeton d’accès, le test échoue avec un résultat BAD_JSON : l’échange n’a pas renvoyé ce qu’il faut à la connexion, ce qui signifie presque toujours que le Client ID ou le Client Secret ne correspond pas. Le test n’utilise pas votre pickup_address et ne vérifie pas que votre customer_id peut réellement passer des livraisons : un test réussi avec une mauvaise adresse ou un mauvais Customer ID est donc possible, et ces erreurs n’apparaissent que plus tard, au devis ou à la création d’une livraison. Si vous lancez le test avant d’enregistrer des identifiants, le résultat est seulement une vérification simulée : enregistrez les vrais identifiants et testez à nouveau pour un résultat réel.

Mapping / choisir un modèle#

Uber Direct n’a pas besoin de mapping de commandes : elle traite des livraisons, pas des commandes. Ce que vous confirmez ici, c’est le flux de livraison suivi par chaque demande : un devis vient d’abord, puis une livraison est créée à partir de ce devis — créer une livraison porte toujours le devis dont elle vient, il n’y a donc pas de création directe sans devis. L’enlèvement vient du JSON pickup_address de la connexion, et chaque demande prend son adresse de destination, son contact et ses articles depuis l’envoi dans ce système. Avant d’activer, lancez un devis réel et une livraison de test vers votre propre adresse, puis comparez le prix coté, l’adresse d’enlèvement telle qu’interprétée depuis le JSON et les détails de destination avec l’envoi.

Flux de livraison Uber Direct : jeton d’abord, puis devis, puis création depuis le devis, puis suivi.

Activer#

Après activation, les envois de ce système peuvent demander des livraisons Uber Direct : la connexion échange un jeton au besoin, cote la livraison sous votre Customer ID, crée la livraison depuis le devis accepté, conserve le statut de la livraison sur l’envoi et peut annuler une livraison pas encore enlevée. Surveillez les premières livraisons réelles dans Runs / Logs avant de laisser la connexion sans surveillance — surtout le premier devis, car le test ne vérifie ni l’adresse d’enlèvement ni le Customer ID.

Ce que cette connexion ne fait pas : elle n’importe pas les commandes du marketplace Uber Eats dans ce système, ne synchronise ni menus ni catalogues de magasin et ne règle ni la paie des coursiers ni la facturation Uber à votre place. Elle se limite à coter, créer, suivre et annuler des livraisons Uber Direct pour les envois que vous passez par elle.

FAQ#

Le test échoue et aucun jeton d’accès ne revient — BAD_JSON

L’échange de jeton n’a pas renvoyé de jeton d’accès, la connexion n’avait donc rien à utiliser et a signalé BAD_JSON. La cause habituelle : le Client ID ou le Client Secret ne correspond pas — l’un a été mal copié, le secret a été tronqué, ou les identifiants d’une autre app ont été utilisés.

Retournez sur direct.uber.com → Developer → votre app → API credentials et recopiez la paire depuis cette même page : Client ID dans client_id et Client Secret, en entier et de la même app, dans client_secret. Puis testez à nouveau.

Le test réussit, mais les devis ou livraisons échouent tout de suite

Le test ne prouve que l’échange de jeton avec client_id et client_secret. Il n’utilise pas votre pickup_address et ne vérifie pas votre customer_id : un mauvais Customer ID ou une adresse d’enlèvement défectueuse passe donc le test et n’échoue que lorsqu’un devis ou une livraison réelle essaie de tourner sous ce compte client, depuis cette adresse d’enlèvement.

Vérifiez les deux valeurs que le test ne couvre pas : customer_id contre direct.uber.com → Developer → Customer ID, et pickup_address contre la forme JSON de l’étape de saisie, caractère par caractère. Corrigez celle qui est fausse, enregistrez, puis refaites le devis.

J’ai mis le Customer ID à la place du Client ID, ou l’inverse

Les deux ID se ressemblent, mais ils font des choses différentes et viennent de pages différentes. Le Client ID appartient à votre app et sert, avec le Client Secret, à échanger un jeton. Le Customer ID désigne votre compte client Uber Direct et figure dans le chemin de livraison lui-même : /v1/customers/{customer_id}/deliveries. Inversés, l’échange de jeton ou la demande de livraison échoue alors même que les deux champs sont remplis.

Remettez chaque ID dans son propre champ, depuis sa propre page : Client ID depuis direct.uber.com → Developer → votre app → API credentials, dans client_id, et Customer ID depuis direct.uber.com → Developer → Customer ID, dans customer_id. Enregistrez, puis testez à nouveau.

Les livraisons échouent à cause de l’adresse d’enlèvement, alors que le test a réussi

C’est le comportement attendu avec une adresse défectueuse : le test de connexion ne regarde jamais pickup_address, il ne peut donc pas détecter un problème d’adresse. L’adresse n’est utilisée qu’au moment où une livraison est réellement passée, et c’est là qu’une chaîne JSON mal formée — street_address tapé en texte simple au lieu d’un tableau, ou des guillemets courbes collés depuis un document — bloque la demande.

Réécrivez pickup_address à la main sous la forme exacte de l’étape de saisie : {"street_address":["20 W 34th St"],"city":"New York","state":"NY","zip_code":"10001","country":"US"}, avec vos propres valeurs — street_address comme un tableau entre crochets, des guillemets droits anglais partout, et aucun texte supplémentaire avant ou après le JSON. Enregistrez, puis repassez la livraison.

J’ai perdu le Client Secret — il ne s’affiche plus

C’est le fonctionnement de la page API credentials : le Client Secret ne s’affiche qu’une seule fois, au moment de sa création. Ce moment passé, la page n’affiche plus la valeur : un secret non conservé ne peut donc pas être relu depuis la page.

Créez un nouveau Client Secret pour la même app sur direct.uber.com → Developer → votre app → API credentials, copiez-le immédiatement cette fois, collez-le dans client_secret sur la connexion et conservez-en une copie en lieu sûr. Puis testez à nouveau : la connexion échangera un jeton avec le nouveau secret.

La création d’une livraison demande d’abord un devis

C’est le flux normal d’Uber Direct, pas une erreur dans vos valeurs : une livraison se crée toujours depuis un devis. Le devis fixe d’abord les détails et le prix de la livraison, et l’étape de création emporte ce devis avec elle — il n’existe pas de voie séparée de création directe qui sauterait le devis.

Suivez le flux dans l’ordre : demandez d’abord un devis pour l’envoi, vérifiez le prix et les détails cotés, acceptez-le, puis créez la livraison depuis ce devis. Si un devis a expiré, demandez un devis frais et créez depuis le nouveau au lieu de réutiliser l’ancien.