Recevoir des commandes de DoorDash
Notre pipeline d’intégration Marketplace est actuellement au maximum de sa capacité. Nous n’acceptons pas de nouveaux partenaires pour le moment pendant que nous développons des outils libre-service pour l’intégration des commerçants. Veuillez remplir le formulaire d’intérêt pour l’intégration de Marketplace pour communiquer avec DoorDash avant de développer votre intégration.
L’image ci-dessous présente un aperçu du fonctionnement de notre OrderAPI.
Recevoir des commandes de DoorDash
DoorDash a également un point d’ancrage Web qui vous informe de l’arrivée de nouvelles commandes en cours. Ce point d’ancrage Web contient le même en-tête d’authentification que le point d’ancrage Web décrit dans Réception des mises à jour de l’état du menu. L’URL pour recevoir les commandes peut être la même que celle du menu, ou une autre. Pour l’instant, la configuration de l’URL est un processus manuel; veuillez donc communiquer avec DoorDash. Ces demandes contiendront des charges utiles au format suivant :
{
"event": {
"type": "OrderCreate",
"status": "NEW"
},
"order": "<Order json object>"
}
L’objet Order est entièrement détaillé dans notre documentation Swagger, et nous avons également inclus un exemple ici. Cet objet Order contient un champ id dont vous aurez besoin plus tard pour confirmer la commande avec le point de terminaison PATCH, veuillez donc en faire le suivi. Toutes les commandes entrantes auront l’état NEW.
Champs importants
special_instructions (facultatif) : DoorDash peut permettre aux clients de saisir des instructions spéciales pour un article donné. Ce paramètre, activé pour le commerce, peut être configuré pour empêcher la saisie d’instructions spéciales ou pour autoriser des instructions spéciales jusqu’à une longueur maximale spécifiée.
is_tax_remitted_by_doordash : Lorsqu’un commerce est situé dans un État qui a une loi de facilitation du marché, DoorDash est responsable de remettre les taxes. DoorDash transmet avec la commande un indicateur pour préciser si DoorDash doit remettre la taxe.
tax_amount_remitted_by_doordash : Si is_tax_remitted_by_doordash est VRAI, ce champ indique le montant de la taxe remise.
estimated_pickup_time : Il s’agit de l’heure estimée à laquelle le Dasher arrivera au commerce, calculée selon un algorithme interne de DoorDash. Celui-ci sera utilisé si le temps de préparation n’est pas retourné dans le message de confirmation de commande du fournisseur (les détails sur ce champ seront indiqués plus loin dans ce document).
delivery_short_code : Ce champ peut être utilisé pour transmettre un identifiant de livraison abrégé unique qui peut être envoyé à l’application Dasher pour le ramassage des commandes.
fulfillment_type : Ce champ peut être utilisé pour préciser si la commande doit être livrée par un Dasher, livrée par le commerçant (autolivraison) ou ramassée par le client. Les détails des valeurs attendues peuvent être trouvés dans le modèle de commande.
experience : Ce champ peut être utilisé pour savoir si la commande a été passée sur Doordash, Caviar ou Storefront. Les détails des valeurs attendues peuvent être trouvés dans le modèle de commande.
merchant_tip_amount : Le montant du pourboire laissé au personnel par l’utilisateur final.
Confirmer les commandes
PATCH /api/v1/orders/{id}
Une fois que vous avez reçu une commande, vous devrez informer DoorDash si vous êtes en mesure de la traiter. Incluez le id de la commande (reçu du point d’ancrage Web) dans les paramètres de l’URL. Les partenaires peuvent utiliser des méthodes de confirmation de commande asynchrones ou synchrones.
Confirmation de commande synchrone
Confirmez la commande avec un appel de point d’ancrage Web de commande DoorDash. Renvoyez 200 pour une commande réussie, une réponse autre que 2xx sera traitée comme un échec de commande. Les charges utiles de réponse sont les mêmes que les charges utiles de confirmation de commande asynchrones. Le délai d’attente HTTP actuel est supérieur à 1 minute, alors si vous prévoyez que les appels prendront régulièrement une vingtaine de secondes, nous préférons plutôt les confirmations asynchrones.
Confirmation de commande asynchrone
Si vous avez reçu la commande, mais que vous souhaitez mettre à jour le statut plus tard, indiquez-le avec un code d’état 202. Veuillez faire un suivi en utilisant le point de terminaison de confirmation de commande pour confirmer l’état de la commande comme étant un succès ou un échec avec une raison d’échec associée, le cas échéant. Si vous ne confirmez pas la commande dans les 3 à 8 minutes, DoorDash traitera la commande comme un échec en raison d’un délai de confirmation de commande expiré. Cette entente de niveau de service de 3 à 8 minutes différera par commande en fonction du moment où la commande a été créée et du moment où un planificateur est exécuté du côté de DoorDash pour marquer les commandes comme périmées. Veuillez vous assurer que les systèmes sont en mesure de respecter cette entente de niveau de service de 3 à 8 minutes, sinon vous constaterez un nombre élevé d’annulations de commandes.
Dans le cas d’une confirmation de commande asynchrone, DD renverra :
| Code d’état | Message de réponse | Signification |
|---|---|---|
| 202 | OK | La confirmation de commande est acceptée. |
| 400 | Mauvais format de demande; la commande a déjà été confirmée; expiration du délai de confirmation de commande. | |
| 404 | Il n’existe pas de commande pour l’identifiant fourni. | DD ne trouve pas l’enregistrement de la commande avec l’identifiant de commande fourni. |
| 500 | Erreur lors du traitement de la confirmation de commande du commerçant | Erreur interne du serveur |
Champs importants
prep_time (facultatif) : Les heures de ramassage des Dashers sont déterminées par défaut par un algorithme interne de DoorDash et envoyées dans estimated_pickup_time. De plus, il existe un paramètre prep_time disponible dans la charge utile de confirmation de commande qui est un objet Datetime. Ce paramètre peut être utilisé comme intrant de l’algorithme interne de DoorDash. Il est facultatif et ne doit être utilisé que s’il existe une logique distincte précisant un temps de préparation différent. Ne renvoyez pas la valeur du champ estimated_pickup_time de DoorDash dans ce champ, car celui-ci se situe en aval de la logique du temps de préparation de DoorDash et entraînera des estimations excessives du temps de préparation.
Remarque : l’heure doit être en UTC.
Remarque : la logique d’affectation des Dasher de DoorDash n’utilise pas le temps de préparation pour les commandes planifiées. Nous tenterons toujours que le ramassage de la commande survienne 10 minutes avant le début de la fenêtre de livraison indiquée.
Option 1 : Utiliser les temps de préparation du modèle DoorDash (recommandé)
La charge utile doit avoir le format suivant et les détails sont également fournis dans la section Point de terminaison de la commande :
{
"merchant_supplied_id": merchant provided order id,
"order_status": "success" or "fail",
"failure_reason": string detailing reason for failure
}
Option 2 : Utiliser les temps de préparation calculés par le fournisseur/commerçant
S’il existe une logique distincte pour indiquer les temps de préparation par le fournisseur ou le commerçant, vous pouvez alors transmettre la charge utile suivante, qui comprend un temps de préparation autocalculé.
{
"merchant_supplied_id": merchant provided order id,
"order_status": "success" or "fail",
"prep_time": a datetime object with the time you expect the order to be prepared by in UTC,
"failure_reason": string detailing reason for failure
}
Émission automatique des commandes (AOR)
L’émission automatique des commandes (AOR) est une fonctionnalité DoorDash que les commerçants peuvent utiliser pour améliorer la qualité des aliments et réduire les temps d’attente des Dasher. Cette fonctionnalité fait en sorte de retenir une commande en préparation jusqu’à ce qu’un Dasher atteigne la distance désignée du restaurant (c’est-à-dire 500 mètres). Une fois que le Dasher a atteint cette distance, DoorDash enverra un événement d’émission au système de PDV pour la préparation des aliments. Le moment de l’arrivée du Dasher jusqu’au moment où la nourriture est prête à être ramassée devrait être plus précis avec l’émission automatique des commandes et est avantageux surtout pour les restaurants à service rapide.
Un nouvel appel sera déclenché vers un point de terminaison configuré, fourni par le commerçant, lorsqu’un Dasher se trouve à proximité du commerce. Lorsqu’un commerçant confirme la commande, il peut transmettre son numéro de commande interne dans le champ merchant_supplied_id et DoorDash enregistrera cette valeur en tant que client_order_id. Cette valeur sera incluse dans la charge utile émise. Celle-ci inclura également des informations sur le véhicule du Dasher pour faciliter le transfert chez les commerçants qui prennent en charge la livraison en bordure de trottoir. Un exemple se trouve dans la référence.
Mises à jour des événements de commande
Actuellement, DoorDash ne sait pas quand la nourriture est prête pour le ramassage et ne peut donc pas transmettre cette information aux Dashers. Cela se traduit par une expérience de ramassage stressante pour les Dashers et les commerçants, car tous les Dashers qui attendent leur commande se rassemblent à l’extérieur des commerces et s’attendant à ce que la prochaine commande soit la leur.
Pour corriger la situation, nous avons introduit la possibilité pour les commerçants de transmettre les événements. Une fois que la commande est prête pour le transfert, les commerçants peuvent l’indiquer à DoorDash, qui informera les Dashers. Les commerçants incluront la valeur« id » de la commande (qu’ils auront reçu du point d’ancrage Web de création de la commande) dans les paramètres d’URL. Vous trouverez plus de détails dans la section « Évènements de commande de correctifs » du document sur les points de terminaison de la commande.
Échecs de commande – Raisons d’échec souhaitées
Lors de l’échec d’une commande, il est important d’inclure le paramètre failure_reason. Celui-ci est essentiel au suivi des pannes et à la résolution des problèmes du système. Vous trouverez ci-dessous quelques exemples d’erreurs détaillées de failure_reason et une description de la situation pour laquelle DoorDash s’attend à les recevoir. Veuillez noter que vous pouvez fournir toute failure_reason personnalisée décrivant une cause spécifique de l’échec d’une commande. Il n’est pas nécessaire que la valeur failure_reason renvoyée corresponde nécessairement à l’un des exemples ci-dessous.
| Raison de l’échec (failure_reason) | Description |
|---|---|
| Commerce non disponible – Problème de connectivité | La commande a été reçue lorsque le commerce avait des problèmes de connectivité/de réseau au niveau du PDV (temporaire). |
| Commerce non disponible – Heures désynchronisées | La commande a été reçue lorsque le commerce était fermé (heures incorrectes). |
| Commerce non disponible – Fermé ou en rénovation | La commande a été reçue alors que le commerce était fermé (de façon permanente comme les fermetures de commerces, des rénovations, etc.) |
| Article non disponible – [Nom de l’article] – [Identifiant de l’article] – En rupture de stock | Les articles ou les options d’articles de la commande sont en rupture de stock. Précisez quel article a causé l’erreur. |
| Articles non disponibles – [Nom de l’article] – [Identifiant de l’article] – Non vendu dans ce commerce | Les articles ou les options d’articles de la commande ne sont pas vendus à ce commerce et ne devraient pas figurer au menu. Précisez quel article a causé l’erreur. |
| Échec de la vérification commerciale de la commande | La commande a échoué en raison de règles commerciales du côté Mx (options requises non marquées, quantité maximale dépassée, problème d’adresse, etc.). Il est préférable de définir un échec par validation commerciale. |
| Erreur d’expiration de délai – 504 | Expiration du délai de la passerelle en raison de problèmes de connectivité (erreur 504) |
| Mauvaise passerelle – 502 | Réponse non valide reçue (erreur 502) |
| Autres – 500 | Autres problèmes (erreurs 500) |
Pour des raisons d’échec de type « rupture de stock », nous recommandons aux partenaires d’inclure la valeur merchant_supplied_id de l’article ou du modificateur, ainsi que le nom de l’article/du modificateur à l’origine de l’échec de la commande afin que les systèmes internes de DoorDash puissent prendre des mesures correctives automatisées pour résoudre le problème et empêcher d’autres échecs de commandes pour ce commerçant.
Mises à jour après confirmation de commande
DoorDash a ajouté une nouvelle fonctionnalité à OpenAPI pour permettre aux commerçants d’annuler des commandes qui ont déjà été acceptées. Bon nombre de nos commerçants à intégration aux PDV ont configuré ceux-ci pour accepter et confirmer automatiquement les commandes tant que la commande passe un ensemble de vérifications. Parfois, les commandes sont initialement confirmées automatiquement, mais doivent ensuite être annulées pour diverses raisons. Dans ce scénario, le commerçant doit appeler le service de soutien de DoorDash pour amorcer l’annulation, ce qui peut prendre beaucoup de temps pour les deux parties. Grâce à cette fonctionnalité, les commerçants pourront amorcer l’annulation d’une commande par l’intégration du PDV.