I’m exploring how n8n could handle workflows such as new order alerts, restaurant notifications, delivery status updates, and customer notifications. What would be the best way to connect these workflows using webhooks and APIs?
Hello @robertwilliam I would keep the workflows loosely coupled rather than putting everything into one large workflow. Use webhooks as the entry points and APIs to communicate with the external services.
Order API
↓ Webhook
n8n → Validate → Save order
↓
Execute Workflow / Queue
├── Restaurant notification
├── Delivery update
└── Customer notification
For production, I would also make each event idempotent, store the order/event ID, and let failed notifications retry independently. That way, a problem with the delivery API doesn’t block the restaurant or customer notification.
Hi @robertwilliam Yes, this fits n8n well. The cleanest setup is event-driven:
- One Webhook in n8n that your app backend calls on every order event (
order.created,order.accepted,status.changed, etc.), with the event type in the body. - A Switch node on the event type, routing each one to its own branch or sub-workflow.
- Notification nodes per audience: restaurant (Telegram, WhatsApp or email), customer (Twilio SMS or push via an HTTP Request to Firebase), and internal alerts (Slack).
- Set the Webhook to respond immediately, so your app never waits on n8n. Keep the order state in your own database, not in n8n.
Delivery partners that send status webhooks can post to the same endpoint.
Hi @robertwilliam
Make n8n the event orchestrator rather than putting all the logic into one workflow.
Each workflow can then call the required APIs independently. This also makes retries and failures much easier to handle without affecting the other processes.
Me too. I think using webhooks for events like new orders and delivery-status changes makes more sense than constantly polling the API. Then n8n can route each event to the right notification workflow and use API calls when it needs to fetch or update additional order details.
Hey @robertwilliam
I can help design an n8n workflow architecture connecting orders, restaurants, delivery services, and customers through webhooks and APIs. The setup can centralize order events and automatically trigger the right notifications at each stage, while keeping the workflows scalable and easy to maintain.
Receive new-order webhooks
Route orders to restaurants
Track delivery status
Trigger customer notifications
Add retries and error handling
Everyone’s covered the routing side well (webhook in, Switch out, one workflow per audience). One thing I’d add before you build: decide where the order itself lives.
A delivery order isn’t a single event. It’s a job that runs for 30-60 minutes and moves through steps: placed → accepted → preparing → picked up → delivered (or cancelled / refunded). If each n8n workflow only reacts to the event in front of it, a few problems show up fast:
- Events arrive out of order or twice. “Picked up” lands before “accepted”, or a retry sends “delivered” again. Without a current status to check against, you’ll notify the customer twice or in the wrong order.
- Nothing happens when nothing happens. The restaurant never accepts, or the rider goes quiet. Webhooks only fire on events, so a stuck order sits unseen unless something checks “accepted for more than 10 minutes and still not picked up?”
- Some steps need a person. Cancellations, refunds and reassigning a rider are judgement calls. Someone needs to see the order, act on it, and leave a record of who did what.
What’s worked for me is treating each order as a small state machine. Keep one record per order with its current status and the moves it’s allowed to make next. When an event arrives, n8n checks it against that status and skips anything that doesn’t fit. A separate scheduled workflow looks for orders stuck in one status too long and sends those to a person. Then n8n does the work (notify, call APIs, retry), and the order record is the single source of truth about where each order is.
Even a simple orders table with status, updated_at and an event log gets you most of the way. Map out the statuses and the allowed moves between them first, then build the workflows around that.