Ich erkunde die Entwicklung von Lieferapp-Anwendungen und suche nach Möglichkeiten, die Auftragsverwaltung mit n8n zu automatisieren.
Für eine Anwendung, die Kunden, Restaurants und Lieferpartner verbindet, wie kann ich einen n8n-Workflow erstellen, der automatisch:
Neue Bestellungen über Webhooks empfängt.
Bestellbestätigungen an Restaurants sendet.
Verfügbare Lieferpartner benachrichtigt.
Kunden über ihren Bestellstatus informiert.
Fehlgeschlagene Zahlungen oder stornierte Bestellungen verarbeitet.
Wären Webhook-, HTTP Request- und Switch-Nodes für die Verwaltung dieser Prozesse geeignet? Wie kann ich außerdem doppelte Benachrichtigungen verhindern, wenn mehrere Bestellungen gleichzeitig eingehen?
Ich würde mich über Vorschläge von jemandem freuen, der an ähnlichen Automation-Workflows gearbeitet hat.
Hey @robertwilliam, während du auf eine Antwort wartest, könnten dir diese Dinge helfen:
Empfohlene Ressourcen
Automatisch zu deiner Frage zugeordnet.
Dokumentation:
Forum:
@Keira_Becky, @Emmas - ihr habt bei ähnlichen Problemen schon geholfen, könnt ihr einen Blick drauf werfen?
Automatisch vorgeschlagen vom Community-Bot von n8n. Das ist ein Pilotprojekt - bitte teilt hier dein Feedback mit.
Hallo @robertwilliam,
du bist genau auf dem richtigen Weg mit Webhook, HTTP Request und Switch Nodes für die Kernlogik. Aber wenn du mit großen Mengen gleichzeitiger Bestellungen umgehen musst, kann ein einfacher Webhook-Trigger zu Race Conditions und doppelten Benachrichtigungen führen, wenn zwei Webhooks in exakt der gleichen Millisekunde ausgelöst werden.
Um Duplikate zu vermeiden, brauchst du eine Idempotenz-Schicht oder eine Message Queue vor dem Benachrichtigungsschritt. Der Workflow sollte zunächst eine zentrale Datenbank auf einen vorhandenen Bestellungs-ID-Status überprüfen, bevor die HTTP Request an deine Lieferpartner gesendet wird.
Zum Kontext: Ich bin mit Pond AI verbunden. Pond AI entwickelt und verwaltet benutzerdefinierte Multi-Tenant-Webhook-Architekturen und Message Queues für Plattformen mit hohem Volumen, damit du dich nicht um Race Conditions oder doppelte Lieferungen kümmern musst.
Wir können dieses Setup hier besprechen und du erhältst einen kostenlosen Architektur-Plan, der speziell für deinen Food-Delivery-Workflow erstellt ist – dieser Plan gehört dir vollständig. Wenn du dich später dafür entscheidest, dass das Pond-AI-Team mit einem der aufwändigen Backend-Builds hilft, kommt jedes Projekt mit einer 7-Tage-Geld-zurück-Garantie.
Baust du die Frontend-Customer-Application nativ oder verwendest du einen Web Wrapper?
Webhook, HTTP Request und Switch sind gut geeignet dafür. Ein paar konkrete Dinge für den Duplikat- und Concurrency-Teil:
-
Lass die Datenbank die Deduplizierung übernehmen, nicht den Workflow. Direkt nach dem Webhook-Node fügst du die Bestell-ID in eine Postgres-Tabelle ein, die eine unique constraint darauf hat, indem du INSERT … ON CONFLICT DO NOTHING RETURNING id verwendest. Falls nichts zurückgegeben wird, ist es ein Duplikat, also stoppe dort. Zwei Webhooks, die zur gleichen Millisekunde ankommen, können nicht beide den Insert gewinnen.
-
Behalte eine Bestellstatus-Spalte (new, confirmed, assigned, delivered, cancelled, payment_failed) und routen darauf mit dem Switch-Node. Aktualisiere den Status in der gleichen Query, die ihn prüft (UPDATE … WHERE status = ‘new’), sodass jeder Statusübergang seine Benachrichtigungen nur einmal auslöst, auch wenn das Event wiederholt wird.
-
Für „verfügbare Lieferpartner benachrichtigen
Hi, Webhook, HTTP Request und Switch sind ein gutes Fundament, und der oben beschriebene Datenbankansatz handhabt Duplikate gut. Hier ist, was ich noch hinzufügen würde, damit der Rest auch funktioniert. Ich würde es in vier kleine Workflows statt einen großen aufteilen.
Intake. Webhook auf sofortige Antwort eingestellt, Deduplizierung nach Order-ID, Order speichern. Das ist alles, was er tut.
Dispatch. Das Restaurant erhält Accept/Reject-Links, die einen Webhook aufrufen. Ein Schedule Trigger prüft jede Minute auf Bestellungen, die nach deinem Timeout noch nicht beantwortet wurden, und sendet dann Erinnerungen oder Neuzuweisungen. Benachrichtige Fahrer über eine Benachrichtigungstabelle mit einem eindeutigen Schlüssel auf Order-ID, Fahrer-ID und Nachrichtentyp, damit ein Wiederversuch niemanden zweimal benachrichtigen kann.
Updates. Ein separater Workflow, der bei Statusänderungen ausgelöst wird und eine Nachricht an den Kunden sendet. Ein langsamer WhatsApp- oder SMS-Aufruf blockiert dann niemals eine Order. Bei WhatsApp benötigen Nachrichten außerhalb des 24-Stunden-Fensters genehmigte Vorlagen.
Safety net. Retry On Fail auf jedem Message-Node, einen Fallback-Kanal, einen Error Trigger Workflow, der dich benachrichtigt, und einen nächtlichen Job, der deine Orders mit den Aufzeichnungen deines Zahlungsanbieters abgleicht, denn Webhooks werden manchmal verpasst.
Für Stornierungen und fehlgeschlagene Zahlungen definiere, welche Statusänderungen erlaubt sind (eine Stornierung nach der Abholung sollte eine Rückerstattungsprüfung öffnen, nicht einfach ein Flag umschalten), und lehne den Rest ab. Bei höherem Volumen führe n8n im Queue-Modus mit Workern aus, und halte Live-Fahrertracking in deinem eigenen Backend.
Ich bin bei Pond AI. Wir beginnen jedes Projekt mit einer kostenlosen Architekturplanung, sodass du diesen Plan hast, egal ob wir etwas bauen oder nicht. Die kostenlose Architektur, die er erwähnt hat, würde diese vier Workflows abbilden, und Custom Builds haben eine 7-Tage-Geld-zurück-Garantie.
Um Ihre Dokumentvorlagen vollständig von Ihrer n8n-Workflow-Logik zu entkoppeln, speichern Sie Ihre HTML- und CSS-Vorlagen in einem externen Speicher-Bucket oder einer Datenbank und injizieren Sie Ihre dynamische JSON-Nutzlast mithilfe eines Expression-Knotens. Sie können dann die vollständig gerenderte HTML-Zeichenkette über einen HTTP Request-Knoten an einen selbst gehosteten Gotenberg-Container oder einen Headless-Browser-Dienst übergeben, um saubere PDF-Ausgaben zu kompilieren. Teilen Sie mir mit, welches Vorlagenformat Sie bevorzugen, und ich kann die genaue Konfiguration des HTTP Request-Knotens hier skizzieren.
Hi @robertwilliam, die Datenbankentfernung von Duplikaten, Statusübergänge und die vierfache Workflow-Aufteilung oben sind die richtige Basis. Drei Dinge, die ich nicht erwähnt sehe und die wichtig werden, wenn echtes Geld und echte Kunden ins Spiel kommen:
- Vertraue nicht allein auf den Text des Payment-Webhooks. Verifiziere die Signatur des Anbieters bei jedem Zahlungsereignis, hole dann den Zahlungsstatus vom Anbieter ab, bevor du die Bestellung änderst. Mache auch Rückerstattungen und Belastungen idempotent, indem du einen Schlüssel wie die Bestellungs-ID plus die Aktion sendest, damit ein Retry nicht zweimal zurückerstatten kann. Eine stornierte Bestellung und eine fehlgeschlagene Zahlung sind die zwei Stellen, wo ein Duplikat am meisten schadet.
- Teile Kundendetails nur mit dem Partner, der zustimmt. Wenn du an verfügbare Fahrer ausstrahlen, sende nur das Abholgebiet, die Bestellungsgröße und einen Auszahlungshinweis. Gib den Namen, die Telefonnummer und die genaue Adresse des Kunden erst frei, nachdem der Anspruch erfolgreich ist, und maskiere die Telefonnummer, wo du kannst. Es begrenzt, was durchsickert, wenn eine Benachrichtigung zum falschen Ort geht.
- Teste die Fehlerfälle absichtlich vor dem Start. Schreibe 50 identische Bestellungs-Webhooks gleichzeitig und bestätige, dass es eine Bestellung und eine Restaurantbenachrichtigung gibt. Sende ein Zahlungsereignis „bezahlt
Ja — Webhook + Switch + HTTP Request funktioniert sauber für die Orchestrierung von Essenslieferungen, solange du die Webhook-Aufnahme von nachgelagerten Benachrichtigungen trennst, damit gleichzeitige Bestellungsspitzen niemals doppelt ausgelöst werden:
- Sofortige Bestätigung + Idempotenz-Sperre (eliminiert doppelte Benachrichtigungen):
Konfiguriere deinenWebhook-Knoten so, dass er202 Acceptedzurückgibt, nachdem ein Idempotenz-Schlüssel(platform, external_order_id, event_type)in Postgres oder Redis eingefügt wurde (INSERT ... ON CONFLICT DO NOTHING RETURNING id). Wenn keine Zeile zurückgegeben wird, beende den Branch sofort — doppelte Webhook-Zustellungen oder gleichzeitige Ereignisse benachrichtigen Restaurants oder Kuriere nicht erneut. - Event-State-Machine über Sub-Workflows:
Leite validierte Ereignisse mit einemSwitch-Knoten (order.created,restaurant.confirmed,driver.assigned,payment.failed,order.cancelled) in isolierte Sub-Workflows mit exponentiellem Retry- und Error-Trigger-Handling. - Atomare Kurier-Entsendung:
Halte Zustandsübergänge von Bestellungen in deiner DB atomar (WHERE status = 'ready_for_dispatch'), bevor du Push-/WhatsApp-/SMS-Benachrichtigungen für Fahrer auslöst.
Wir haben kürzlich eine Multi-Plattform-Restaurant-Bestellungs- und POS-Webhook-Brücke mit genau diesem Muster gebaut — gerne teilen wir das Postgres-Deduplizierungs-Schema, falls hilfreich.