Dira Bridge · POS and kitchen connectivity
Connect digital orders to the kitchen.
Dira Bridge takes every canonical order into the store's POS through one gateway, with an adapter for each POS. When a POS stops responding, Bridge retries, alerts the store and keeps a clear path to recovery.
Normal
Mapped, injected and fired to the kitchen, with every step timed.
POS unavailable
Degraded mode, retries with backoff and an idempotent replay.
- +0msCANONICALOrder DR-48213 ready for POS3 items · 4 modifiers · prepaid
- +38msGATEWAYMapped to POS menu IDsTender: marketplace prepaid
- +212msADAPTERCheck openedPOS check #2041 · store S-0142
- +240msKITCHENFired to kitchenFire time aligned to courier ETA
- +9m 14sSTATUSReady event receivedSynced to marketplace and Store
The POS is where digital orders get stuck.
A marketplace order is only real once the kitchen sees it. That last step crosses systems no single team owns.
Every POS is different
Menu IDs, tender types and order types vary by system and often by store. Point-to-point integrations break with each variation.
Outages turn into missing orders
A store controller that drops offline for a few minutes can leave orders accepted on the marketplace and absent from the kitchen.
Recovery depends on who notices
Without alerts and a trace, staff find out when a courier arrives. Manual entry happens off the record, and orders get keyed twice.
One gateway. An adapter for each POS.
Bridge separates the canonical order from the POS that receives it. The core never speaks a POS dialect. Each adapter speaks one, and nothing else.
Dira platform
Dira core
Canonical order
- Items, modifiers and tender
- Order type and timing
- Event history
Dira Bridge
POS gateway
- Maps items to POS identifiers
- Applies store configuration
- Owns retries and idempotency
Adapter boundary · one per POS
Adapter
POS adapter
- Speaks one POS interface
- Opens checks, fires and voids
- Reports status and heartbeat
Store
POS and kitchen
- Check opened
- Ticket fired to the kitchen
- Ready and void events back
POS connectors are scoped and validated for each deployment. We confirm which POS systems and versions are in scope during onboarding.
See the POS integration modelWhen the POS goes quiet, the order doesn't.
Follow a sample order through a POS outage. Step through each event, then choose how the store recovers and watch all three views stay in step.
BRIDGE TRACE
- 11:42:00DR-48230 ready for POS
- 11:42:05POS unreachable · controller timeout
- 11:42:05Degraded mode on for S-0217
DIRA STORE · LEGACY WEST
New orders still arrive here. Bridge is retrying in the background.
DIRA COMMAND
- POS health
- Unreachable
- Retries
- starting
- Store alerted
- not yet
- Exception
- Open
Illustrative interface · sample data
Configured store by store.
Large networks rarely run one POS setup. Bridge keeps tender, order type, fire timing and failure handling for each store, with every change in the audit history.
- Fire on accept, or hold the ticket until shortly before the courier arrives.
- Decide what happens when retries run out: manual entry or a paused channel.
- See each store's adapter heartbeat beside its settings.
South Lamar S-0142
POS healthy · heartbeat 12s agoBuilt for the last step of every order.
Everything between a canonical order and a ticket on the kitchen screen, with a way back when something fails.
POS gateway
One gateway sits between Dira and every store POS. It applies store configuration, owns retries and keeps the trace for each order.
Adapter-based POS integration
Each POS sits behind its own adapter. Adding or changing a POS changes an adapter, not your order flow.
Connectors scoped and validated per deployment
Order injection
Items, modifiers, tender and order type are mapped to POS identifiers. The check opens and the ticket fires to the kitchen on the store's timing.
Store-specific configuration
Tender mapping, order types, fire timing and failure handling are set per store, so a mixed estate runs on one platform.
Retries and POS health
Failed injections retry with backoff. Adapter heartbeats feed POS health into Dira Command, store by store.
Recovery and manual-entry fallback
When retries run out, the store is alerted in Dira Store and can key the order by hand. Dira records the manual entry against the order, so it is never injected twice.
Technical details
How Bridge moves an order into the POS, what it records and where the adapter boundary sits.
- Gateway
- A single POS gateway between canonical orders and store systems.
- Adapter boundary
- One adapter per POS integration. The core sends canonical orders; adapters translate them and report back.
- Connector status
- POS connectors are scoped and validated per deployment. No POS goes live without validation for that brand's stores.
- Data handled
- Items, modifiers, tender, order type, fire timing, cancellations and voids.
- Events
- Check opened, fired to kitchen, ready, voided and failure events, written to the order's canonical history.
- Idempotency
- One canonical order opens at most one POS check. Replays reuse the order's key.
- Retries
- Backoff retries per store policy. Degraded mode queues new orders and alerts the store.
- POS health
- Adapter heartbeat and injection results per store, visible in Dira Command.
- Manual-entry fallback
- Orders can be keyed by hand from Dira Store during an outage and are recorded against the canonical order.
- Audit history
- Configuration changes and recovery actions are recorded with user and time.
Questions buyers ask
Get every digital order to the kitchen.
Talk through your POS estate with the Dira team and see how Bridge would connect it.