Bestellungen von DoorDash erhalten

Marketplace APIs are limited access

Unsere Pipeline für Marktplatz-Integration ist derzeit ausgelastet. Wir nehmen im Moment keine neuen Partner an, sind aber dabei, Self-Service-Tools für das Onboarding von Anbietern zu entwickeln. Bitte fülle das Formular für Interessenten der Marktplatz-Integration aus, um mit DoorDash in Kontakt zu treten, bevor du deine Integration erstellst.

Das Bild unten zeigt einen groben Überblick über die Funktionsweise unserer Bestell-API.

Erhalt von DoorDash-Bestellungen

DoorDash verfügt auch über einen Webhook, der dich über eingehende neue Bestellungen informiert. Dieser Webhook enthält denselben Authentifizierungsheader wie der unter „Empfangen von Menüstatus-Aktualisierungen“ beschriebene Webhook. Die URL zum Erhalt von Bestellungen kann entweder die gleiche sein wie die der Speisekarte oder eine andere. Derzeit ist dies ein manueller Prozess. Bitte kontaktiere DoorDash, um die URL zu konfigurieren. Diese Anfragen enthalten Payloads im folgenden Format:

{
  "event": {
    "type": "OrderCreate",
    "status": "NEW"
  },
  "order": "<Order json object>"
}

Das Bestellobjekt ist in unserer Swagger-Dokumentation ausführlich beschrieben und wir haben hier auch eine Beispielinstanz aufgenommen. Dieses Bestellobjekt enthält ein id Feld, das du später benötigst, um die Bestellung mit dem PATCH-Endpunkt zu bestätigen, also behalte es im Blick. Alle eingehenden Bestellungen haben den Status NEU.

Wichtige Felder

special_instructions (optional): DoorDash kann Kund:innen ermöglichen, besondere Anweisungen auf Artikelebene einzugeben. Dies ist eine Einstellung auf Anbieterebene und kann so konfiguriert werden, dass die Eingabe besonderer Anweisungen blockiert wird oder besondere Anweisungen bis zu einer bestimmten maximalen Länge zugelassen werden.

is_tax_remitted_by_doordash: Wenn sich ein Anbieter in einem als Marktplatzvermittler ausgewiesenen Staat befindet, ist DoorDash für die Abführung der Steuern verantwortlich. DoorDash sendet eine Markierung an die Bestellung, um zu vermerken, ob die Steuern von DoorDash überwiesen wurden.

tax_amount_remitted_by_doordash: Wenn is_tax_remitted_by_doordash TRUE ist, gibt dieses Feld den Steuerbetrag an, der überwiesen wurde.

estimated_pickup_time: Dies ist der geschätzte Zeitpunkt, zu dem der:die Kurier:in basierend auf einem internen DoorDash-Algorithmus beim Anbieter ankommt. Dies wird verwendet, wenn die Vorbereitungszeit nicht in der Bestellbestätigung vom Anbieter zurückgesendet wird (Details zu diesem Feld später in diesem Dokument).

delivery_short_code: Dieses Feld kann verwendet werden, um eine verkürzte eindeutige Lieferkennung anzugeben, die an die Dasher-App zur Abholung weitergegeben werden kann.

fulfillment_type: Dieses Feld hilft dir, zu verstehen, ob eine Bestellung zur Lieferung durch den:die Kurier:in, zur Lieferung durch den Anbieter („Self Delivery“) oder zur Abholung durch den:die Kund:in gedacht ist. Details zu den erwarteten Werten sind im Bestellmodell zu finden.

experience: Dieses Feld kann verwendet werden, um nachzuvollziehen, ob die Bestellung auf DoorDash, Caviar oder Storefront aufgegeben wurde. Details zu den erwarteten Werten sind im Bestellmodell zu finden.

merchant_tip_amount: Dies ist das Trinkgeld, das Endbenutzer:innen für die Mitarbeitenden hinterlassen.

Bestätigen von Bestellungen

PATCH /api/v1/orders/{id}

Sobald du eine Bestellung erhalten hast, musst du DoorDash mitteilen, ob du sie ausführen kannst. Füge die id der Bestellung (die du vom Webhook erhalten hast) in die URL-Parameter ein. Partner können asynchrone oder synchrone Bestellbestätigungsmethoden verwenden.

Synchrone Bestellbestätigung

Bestätige die Bestellung mit einem DoorDash-Webhook-Call. Gib 200 für eine erfolgreiche Bestellung zurück. Nicht-2xx wird als fehlgeschlagene Bestellung behandelt. Antwort-Payloads entsprechen asynchronen Bestellbestätigungs-Payloads. Die aktuelle HTTP-Zeitüberschreitung beträgt >1 Minute, aber wenn du davon ausgehst, dass die Anrufe regelmäßig länger als ~20 Sekunden dauern, bevorzugen wir stattdessen asynchrone Bestätigungen.

Asynchrone Bestellbestätigung

Wenn du die Bestellung erhalten hast, den Status jedoch zu einem späteren Zeitpunkt aktualisieren möchtest, gib dies mit dem Statuscode 202 an. Bitte verwende den Endpunkt für die Bestellbestätigung, um den Bestellstatus als erfolgreich oder fehlgeschlagen mit einem zugehörigen Fehlergrund zu bestätigen. Wenn du die Bestellung nicht innerhalb von 3–8 Minuten bestätigst, behandelt DoorDash die Bestellung aufgrund einer Zeitüberschreitung bei der Bestellbestätigung als fehlgeschlagen. Dieses 3–8-minütige SLA unterscheidet sich je nach Bestellung in Abhängigkeit von dem Zeitpunkt, zu dem die Bestellung erstellt wurde, bis hin zu dem Zeitpunkt, zu dem auf DoorDash-Seite ein Zeitplaner ausgeführt wird, um Bestellungen als veraltet zu markieren. Bitte stelle sicher, dass die Systeme dieses SLA von 3–8 Minuten einhalten können, andernfalls wirst du ein hohes Aufkommen an Bestellstornierungen haben.

Für eine asynchrone Bestellbestätigung antwortet DD:

Statuscode	Antwortnachricht	Was dies bedeutet
202	OK	Bestellbestätigung ist akzeptiert
400		Ungültiges Anfrageformat; Bestellung wurde bereits bestätigt; Zeitüberschreitung bei der Bestellbestätigung
404	Bestellung mit der angegebenen ID existiert nicht	DD kann den Bestelldatensatz mit der angegebenen Bestell-ID nicht finden
500	Fehler bei der Verarbeitung der Bestellbestätigung des Anbieters	Interner Serverfehler

Wichtige Felder

prep_time (optional): Die Abholzeiten der Fahrer:innen werden standardmäßig von einem internen DoorDash-Algorithmus bestimmt und in der estimated_pickup_time gesendet. Darüber hinaus ist ein Parameter prep_time in der Payload der Bestellbestätigung verfügbar, bei dem es sich um ein Datetime-Objekt handelt. Dies kann verwendet werden, um prep_time als Eingabe für den internen Algorithmus von DoorDash festzulegen. Das Feld ist optional und sollte nur verwendet werden, wenn eine separate Logik eine andere Vorbereitungszeit vorschreibt. Gib in diesem Feld nicht die estimated_pickup_time von DoorDash zurück, da dies der Logik für die DoorDash-Vorbereitungszeit nachgelagert ist und viel zu lange Vorbereitungszeiten zur Folge hätte.

Hinweis: Die Zeit sollte in UTC angegeben werden.

Hinweis: Die DoorDash-Logik hinter der Zuweisung von Kurier:innen beinhaltet keine Vorbereitungszeiten für geplante Bestellungen. Wir zielen immer darauf ab, dass die Bestellung 10 Minuten vor Beginn des angegebenen Abgabe-Zeitfensters abgeholt wird.

Option 1: So verwendest du die Vorbereitungszeiten für das DoorDash-Modell (empfohlen)

Die Payload sollte das folgende Format haben und wird auch im Abschnitt „Bestell-Endpunkt“ beschrieben:

{
  "merchant_supplied_id": merchant provided order id,
  "order_status": "success" or "fail",
  "failure_reason": string detailing reason for failure
}

Option 2: So verwendest du die vom Anbieter/Händler berechneten Vorbereitungszeiten

Wenn es eine separate Logik gibt, um die Vorbereitungszeiten vom Anbieter oder Händler festzulegen, kannst du die folgende Payload einschließlich einer selbstberechneten Vorbereitungszeit übergeben.

{
  "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
}

Automatische Bestellfreigabe (AOR)

Die automatische Bestellfreigabe (AOR) ist eine DoorDash-Funktion, mit der Anbieter die Essensqualität verbessern und die Wartezeiten für Kurier:innen verkürzen können. Dies wird implementiert, indem eine Bestellung im Staging gehalten wird, bis ein:e Kurier:in die angegebene Entfernung vom Restaurant erreicht (z. B. 500 Meter). Sobald sich der:die Kurier:in dieser Entfernung befindet, sendet DoorDash ein Freigabeereignis an das POS-System zur Zubereitung des Essens. Der Zeitpunkt des Eintreffens des:der Kurier:in bis zum Abholen des Essens sollte durch die automatische Bestellfreigabe präziser sein. Dies ist vor allem für Schnellrestaurants von Vorteil.

Ein neuer Anruf, der an einen vom Anbieter bereitgestellten Endpunkt gesendet wird, wenn sich ein:e Kurier:in in der Nähe des Anbieters befindet. Wenn ein Anbieter die Bestellung bestätigt, kann er seine interne Bestell-ID im Feld merchant_supplied_id angeben, dann speichert DoorDash diesen Wert als client_order_id. Dies wird als Teil der Freigabe-Payload gesendet. Dazu gehören auch Informationen zum Fahrzeug der Kurier:innen, um die Übergabe für Anbieter zu erleichtern, die die Lieferung bis zur Bordsteinkante unterstützen. Ein Beispiel kann in der Referenz gefunden werden.

Aktualisierungen des Bestell-Events

Bisher weiß DoorDash nicht, wann das Essen abholbereit ist, und kann diese Informationen daher nicht an Kurier:innen weitergeben. Dies führt zu einem stressigen Abholerlebnis für Kurier:innen und Anbieter, da sich alle Kurier:innen, die auf ihre Bestellung warten, vor den Anbietern drängen, in der Erwartung, dass die nächste Bestellung ihre eigene ist.

Um dies zu beheben, haben wir die Möglichkeit für Anbieter eingeführt, das Ereignis zu teilen. Sobald die Bestellung abholbereit ist, können Anbieter DoorDash mitteilen, dass die Kurier:innen informiert werden sollen. Anbieter fügen die „ID“ der Bestellung (die sie vom Webhook für die Bestellerstellung erhalten sollten) in die URL-Parameter ein. Weitere Informationen findest du im Abschnitt „Patches für Bestellereignisse“ in den Bestell-Endpunkten.

Fehler bei der Bestellung - Gewünschte Fehlergründe

Wenn eine Bestellung fehlschlägt, ist es wichtig, den Parameter failure_reason einzuschließen. Dies ist wichtig, um Ausfälle zu verfolgen und Systemprobleme zu beheben. Im Folgenden findest du einige Beispiele für detaillierte „failure_reason“-Fehler und eine Beschreibung, wann DoorDash sie voraussichtlich erhalten würde. Bitte beachte, dass du jeden benutzerdefinierten failure_reason angeben kannst, der für bestimmte Ursachen von fehlgeschlagenen Bestellungen relevant ist. Der zurückgegebene failure_reason muss nicht unbedingt zu einem der unten aufgeführten Beispielen für eine failure_reason gehören.

Fehlerursache	Beschreibung
Anbieter nicht verfügbar - Konnektivitätsproblem	Bestellung ging ein, als der Anbieter (vorübergehend) Probleme mit der POS-Konnektivität/dem Netzwerk hat.
Anbieter nicht verfügbar - Uhrzeit nicht synchronisiert	Bestellung ging ein, als das Geschäft geschlossen war (falsche Öffnungszeiten).
Anbieter nicht verfügbar - geschlossen oder Umbau	Bestellung ging ein, als das Geschäft geschlossen war (dauerhaft wegen Geschäftsschließung, Umbau usw.)
Artikel nicht verfügbar - [Artikelname] - [Artikel-ID] - Nicht vorrätig	Artikel oder Artikeloptionen in der Bestellung sind 86’ed. Gib an, welcher Artikel den Fehler verursacht hat.
Artikel nicht verfügbar - [Artikelname] - [Artikel-ID] - Nicht bei diesem Anbieter erhältlich	Artikel oder Artikeloptionen in der Bestellung werden nicht im Geschäft verkauft und sollten nicht auf der Speisekarte stehen. Gib an, welcher Artikel den Fehler verursacht hat.
Anbietervalidierung bei Bestellung fehlgeschlagen	Die Bestellung ist aufgrund von Geschäftsregeln auf der Mx-Seite fehlgeschlagen (erforderliche Optionen nicht markiert, maximale Menge überschritten, Problem mit der Adresse usw.). Separate Fehler werden pro Unternehmensvalidierung bevorzugt.
Zeitüberschreitungsfehler - 504	Gateway-Zeitüberschreitung aufgrund von Verbindungsproblemen (Fehler 504)
Schlechtes Gateway - 502	Ungültige Antwort erhalten (Fehler 502)
Sonstiges - 500	Sonstige Probleme (500 Fehler)

Bei „Nicht vorrätig“-Fehlerursachen empfehlen wir Partnern, die merchant_supplied_id des Artikels oder der Alternative zusammen mit dem Namen des Artikels/der Alternative anzugeben, der/die für das Fehlschlagen der Bestellung verantwortlich ist, damit die internen Systeme von DoorDash automatische Korrekturmaßnahmen ergreifen können, um das Problem zu beheben und ein späteres Fehlschlagen von Bestellungen für diesen Anbieter zu verhindern.

Aktualisierungen nach der Bestellbestätigung

DoorDash hat OpenAPI um neue Funktionen erweitert, die es Anbietern ermöglichen, bereits angenommene Bestellungen zu stornieren. Viele unserer POS-integrierten Anbieter sind so eingestellt, dass sie Bestellungen automatisch annehmen und bestätigen, solange die Bestellung eine Reihe von Validierungen besteht. Gelegentlich werden Bestellungen zunächst automatisch bestätigt, müssen dann aber später aus verschiedenen Gründen storniert werden. In solchen Fällen muss der Anbieter den DoorDash-Support anrufen, um die Stornierung zu veranlassen, was für beide Parteien ein zeitaufwändiger Prozess sein kann. Durch diese Funktion ermöglichen wir es Anbietern, Stornierungen auf Bestellebene über die POS-Integration zu veranlassen.