A restaurant on three delivery platforms usually ends up with three tablets on a shelf, each with its own notification sound, each needing somebody to accept the order and read it off a screen. It works until two of them ring at once during service.
The short answer: put an aggregator between the platforms and the kitchen, then send one print call per order. The platforms keep their own apps for status and support, but the ticket that reaches the kitchen has a single format, a single sound and no screen to watch.
Where the tablets actually hurt
| Problem | Why it happens | What changes |
|---|---|---|
| Three different ticket formats | Each app lays out its own | One template you control |
| Orders missed at peak | Two tablets ring at once, one gets ignored | The ticket is physical and does not need acknowledging |
| Retyping into the POS | The tablet is a separate island | The aggregator pushes the order onward |
| No trace of what arrived | The history lives in three apps | One print history, one order reference |
The pattern behind all four is the same: a tablet is a screen for a person, and a kitchen at peak has no spare person.
The architecture
Three pieces, and only the middle one is a decision:
- The platforms. DoorDash, Deliveroo, Uber Eats and the rest each expose orders through their own partner integration.
- An aggregator. HubRise and equivalents normalise those feeds into one order format, which is what makes a single ticket template possible. This is the piece that saves the work.
- A print call. One POST per order to a printer reachable over the internet. No local software, no tablet.
If your platforms are already unified in a POS, the aggregator step may be redundant and the print call can hang off the POS instead. The question to ask is simply where the orders already meet, and to attach printing there rather than building a fourth island.
For platforms that expose only a webhook and nothing else, an automation tool such as Zapier will bridge the gap without code, at the cost of a few seconds of latency.
What the ticket needs that a web order does not
Delivery tickets carry information a shop order never has, and leaving it off is what causes the callbacks:
- The platform name and the platform's own order reference, printed large. When a rider arrives asking for order 4471, nobody wants to search three apps.
- Delivery or collection, at the top. It changes the packaging.
- The requested time, not just the order time. A pre-order for 20:30 arriving at 19:00 must not be cooked immediately, and this is the single most common mistake when moving off tablets.
- Item modifiers on their own indented line, because a rushed reader treats an inline modifier as another item.
- The customer note, in full, at the bottom.
The rest of the layout follows the same rules as any kitchen ticket, and the markup is in the receipt layout reference.
Handling the failure modes specific to delivery
Cancellations after printing. A platform can cancel an order that is already on the pass. Printing a cancellation ticket to the same printer is worth doing: it is louder than a notification nobody is watching.
Modifications. Some platforms allow the customer to change the order before preparation. Print the modification as a new ticket that references the original, rather than reprinting the whole order, so the kitchen does not prepare it twice.
Duplicates from retries. Aggregator webhooks retry. Put the platform's order reference in origin so a repeat is detectable in the print history rather than reprinted. The reliability guide covers the pattern.
Pre-orders. Decide whether the ticket prints on receipt or at preparation time. Printing on receipt is simpler and fine for small volumes; scheduling the print for a lead time before the requested slot is better once pre-orders are common, and it needs the requested time on the ticket either way.
What still needs a screen
Printing does not replace the platform apps entirely. Marking an order ready, communicating with a rider, and handling refunds stay in the app, and the tablet can move off the pass to the office. The goal is not zero screens; it is that no screen sits between an incoming order and the kitchen.
Print a test delivery ticket on the free plan with a realistic payload, including a pre-order time and a two-line customer note, before wiring the aggregator. Layout problems are much cheaper to find on a Tuesday afternoon.
FAQ
Can I print delivery platform orders without a tablet for each app?
Yes. An aggregator normalises the platforms into one order feed, and a single print call sends the ticket to the kitchen. The apps stay for status updates and support, but nothing has to be read off a screen for the order to be made.
What must a delivery ticket show that a shop order does not?
The platform name and its own order reference in large type, delivery or collection at the top, the requested time rather than just the order time, modifiers on their own indented line, and the customer note in full.
What happens if a platform cancels an order after the ticket printed?
Print a cancellation ticket to the same printer. It is louder than a notification nobody is watching, and it lands where the original ticket did, which is the only place the kitchen is actually looking.
How do I stop pre-orders being cooked immediately?
Put the requested time on the ticket, not just the order time, and decide whether to print on receipt or to schedule the print for a lead time before the slot. Printing on receipt without the requested time is the most common mistake.
Why does the same delivery order sometimes print twice?
Aggregator webhooks retry when your endpoint answers slowly. Put the platform's order reference in the origin field so a repeat is detectable in the print history rather than silently reprinted.