A cloud-kitchen and restaurant aggregator wanted a single console that pulled Swiggy + Zomato + own-channel orders for 180+ partner restaurants — with KOT routing, menu sync, and payout reconciliation. We delivered it in five months.
Cloud-kitchens and aggregator-partners run on 15+ tablets per outlet — one for Swiggy, one for Zomato, one for own-channel, one for the POS, one for the KDS. Staff miss orders. Menus drift between channels. Reconciliation is a weekly nightmare. The client wanted one screen, period — and they wanted it to work for 180+ partners on day-one of cut-over.
A central console that ingests orders from all aggregators via their APIs (Swiggy POS API, Zomato Saathi, own-channel webhook), normalises them to a single schema, routes KOTs to one printer, and reconciles payouts.
Single inbox of all orders across all channels, color-coded by source + status, prep-time tracking, accept / reject / re-prep workflow, customer notes, allergen alerts.
One printer per outlet (or kitchen station). All orders, regardless of source, print to the same KOT with a unified format. Source-aware (Swiggy / Zomato / own) for kitchen psychology.
One master menu per restaurant. Map to each channel; push updates with one click. Out-of-stock toggles propagate to all channels in 30 seconds.
Daily ingestion of aggregator settlement files, automated matching to orders, exception queue for ops, daily P&L per outlet per channel.
Aggregator-API integrations as Kafka producers (with retry + DLQ), orders normalised to a unified schema, WebSockets to push to the console in real-time, BullMQ for menu-sync jobs.
We picked the stack for fit, performance under realistic load, and operational simplicity. Here is the breakdown:
Kafka for aggregator integration: aggregator APIs fail in creative ways. Kafka with consumer groups + DLQ handles retries cleanly. We replayed 14 days of historical orders during the Swiggy API revamp last December without losing data.
WebSockets, not polling: the console updates in real-time as orders arrive; staff don't refresh, don't miss, don't double-confirm. WebSocket reconnect logic was a 2-week investment that paid back in week three.
ESC/POS direct over vendor SDK: we wrote ESC/POS bytes ourselves so any 80mm thermal printer worked. Saved on per-outlet hardware procurement.
Aggregator API instability + idempotency.
Aggregator APIs are not stable, not well-documented, and not consistent. Same endpoint returns three different JSON shapes depending on order type. Webhooks fire twice for the same order. Retries have no idempotency keys built in.
We built our own idempotency layer: every inbound message is hashed (sourceId + orderId + status), stored, and de-duped. We replay through Kafka if the console missed a message. We also normalise the three JSON shapes into one schema at ingestion — the console code never has to know which aggregator the order came from.
This is the part of the platform that is invisible when working — and catastrophic when missing. Order rejection rate dropped 22% just from no-more-missed-orders.
We started with a single restaurant partner in a single city — one Swiggy listing, one Zomato listing, one own-channel — for six weeks of brutal feedback. Every aggregator quirk we hit got encoded into the integration layer.
180-partner roll-out was outlet-by-outlet over 12 weeks. Each onboarding was a 2-hour playbook by partner #20 — KOT printer config, menu mapping, payout reconciliation setup.
“Tablet sprawl was killing us. One console, one printer, one menu — that was the entire pitch and it has paid off across 180 partners. ITD's integration layer has survived three Swiggy API revamps without us noticing.”
Operations Director
Restaurant Operations Partner · 3 metros
Build the menu-sync system before the order-ingest system. We did them in parallel; the menu-sync was always one sprint behind ingest, which meant for the first 8 weeks our partners had inconsistent menus across channels. Menu first, orders second.
Aggregator integration, KOT routing, menu sync, payout reconciliation — these are not features, they are infrastructure. We've shipped this for 180+ restaurant partners. Talk to engineers who have built it.
Get a Free Consultation
