Dira Connect · Marketplace ordering
Every marketplace order, in one flow.
Dira Connect receives orders from delivery marketplaces and turns each one into a single canonical order your stores, POS and finance teams can trust. Validation, status sync and recovery happen in one place, with one history per order.
DR-48212
DoorDash · Legacy West
EVENT HISTORY
- 11:42:03Webhook receivedSignature verified
- 11:42:03Canonical order createdIdempotency key matched: new
- 11:42:04Menu mapping validated2 items, modifiers resolved
- 11:42:05AcceptedStatus synced to marketplace
- 11:42:06POS injection failedStore controller timeout
- 11:42:36Retry 1 of 5Backoff 30s
- 11:43:36Retry 2 of 5Store notified · manual entry available
Illustrative interface · sample data. Uber Eats is integrated today; DoorDash and Grubhub adapters are in development.
Marketplace orders arrive in pieces.
Each channel has its own format, its own status rules and its own failure modes. Without one flow, the gaps become someone's job.
Every channel speaks its own format
Item names, modifiers and order states differ by marketplace. Teams end up translating by hand, or trusting a tablet they cannot audit.
Duplicates and dropped webhooks
Marketplaces resend events when a response is slow. Without idempotency, one order can become two tickets in the kitchen, or none.
Status drifts out of sync
When acceptance or ready status never reaches the marketplace, couriers wait, guests cancel and the store takes the blame.
Failures hide until a guest calls
An unmapped modifier or a closed store should raise an exception in seconds, not surface as a refund request the next day.
Where each marketplace stands today.
Connect runs one adapter per marketplace on a shared canonical order model. A new channel joins the same flow instead of a new one.
- UEUber EatsIntegrated
Built into the current Dira release and in use on the platform.
Orders in · status both ways · menu and availability out
- DDDoorDashIn development
Adapter in active development and targeted next. Not yet live.
Orders in · status both ways · menu and availability out
- GHGrubhubIn development
Adapter in active development and targeted next. Not yet live.
Orders in · status both ways · menu and availability out
Status is a fact, not a label. We confirm it with your team before any rollout plan.
See the integration directoryOne order, from webhook to handoff.
Step through a sample Uber Eats order. Advance its state to see what Dira syncs back, then redeliver the webhook to watch idempotency at work.
CANONICAL STATE
Sent to POS
DiraBridgeCanonical order handed to Dira Bridge with tender mapped as marketplace prepaid.
EVENT LOG
1
0
- Order to POS11:42:06 · BridgeQueued for store S-0142
- Accept11:42:05 · Uber EatsAcknowledged
- Order placed11:42:03 · Uber EatsSignature verified · order DR-48213 created
Illustrative interface · sample data
Verified on receipt
Each webhook is checked before anything is written. Unsigned or malformed events never reach the order.
Recorded once
The idempotency key on every event means a resend is acknowledged and ignored. The kitchen sees one ticket.
Synced back
Acceptance and ready status return to the marketplace that sent the order, so courier timing stays honest.
Built for the hard parts of order intake.
Everything between a marketplace webhook and a ticket in the kitchen, handled in one pipeline with one history.
Canonical order model
Every marketplace order is converted into one Dira order format with items, modifiers, tender and timing. Stores, POS and finance read the same record.
One schema for every channel adapter
Menu mapping validation
Items and modifiers are checked against the live Dira Catalog mapping before acceptance. Anything unmapped stops at an exception, not at the POS.
Mapping source: Dira Catalog
Acceptance and status sync
Dira accepts on the store's behalf when the store is open and the order is valid, then sends preparation and ready status back to the marketplace.
Idempotent webhook handling
Each inbound event carries an idempotency key. Redelivered webhooks are acknowledged and ignored, so one order never becomes two.
Duplicates: acknowledged, not reprocessed
Retries and exception queue
Failed steps retry with backoff. When retries run out, the order lands in an exception queue with its full history and a clear next action.
Scheduled orders and cancellations
Future orders are held and released to the store on time. Cancellations void the kitchen ticket through Dira Bridge and close the order cleanly.
Unmapped modifier
DR-48188 · HeightsModifier ‘Extra pickles’ has no mapping in Core menu v41.
EVENT HISTORY
- 11:36:12Webhook received · signature verified
- 11:36:12Canonical order created
- 11:36:13Menu mapping failed · 1 modifier
Technical details
What Connect handles, what it emits and where its boundaries sit.
Architecture and APIs- Channels
- Uber Eats integrated. DoorDash and Grubhub adapters in development, targeted next.
- Data handled
- Orders, items, modifiers, tender, scheduled times, cancellations and order status.
- Inbound events
- Marketplace order, update and cancellation webhooks, verified before anything is written.
- Outbound events
- Acceptance, rejection, preparation and ready status to the originating marketplace. Canonical order events to Bridge, Store, Command and Reconcile.
- Adapter boundary
- One adapter per marketplace. Channel formats stop at the adapter; the core works only with canonical orders.
- Idempotency
- Idempotency key on every inbound event. Duplicate deliveries are acknowledged and never reprocessed.
- Retries
- Automatic retries with backoff on downstream failures. Exhausted retries move to the exception queue with replay.
- Audit history
- Every state change is written to the order's canonical event history, with its time and source.
- Contracts and runtime
- Strict OpenAPI 3.1 contracts. NestJS services on PostgreSQL with an event/outbox model, on the Google Cloud reference deployment.
Questions buyers ask
See your marketplace orders in one flow.
Walk through Connect with the Dira team, using your channels and store setup as the example.