Skip to main content
New event (June 2026). Born directly in v1 — no v0 shape exists.
order.status_updated fires when the KDS (Kitchen Display System) reports that an order advanced its kitchen status: preparation started (preparing), it is ready (ready) or it was dispatched (dispatched). Fire receives the KDS report through the inbound status webhook, validates that it references an event Fire emitted for that order, applies an anti-regression gate (a status never goes backwards: dispatched does not return to ready) and only then emits this event. That is why you receive one event per real advance — no duplicates, no rollbacks.

​
Trigger condition

Fire emits order.status_updated when all of the following are true:
  • The KDS reported a kitchen status for an existing order
  • The status advances the journey (anti-regression gate: preparing → ready → dispatched)
  • The report passed the source-of-truth validation (it references an event Fire emitted for that order)
CoverageAll countries
Statusespreparing → ready → dispatched (monotonic)
Idempotency keyevent.id
Fires more than onceOnce per status advance (max 3 per order); retries share event.id
Data sourcekitchen.source — only kds today; the field stays open for future sources

​
What’s in data

This is a lean (thin) payload — unlike order.completed, it does not carry the full order. It carries what you need to act on a status change: the order’s identity, minimal channel / store refs, the fulfillment type, and the kitchen block (the advance + the full journey). It deliberately omits orderLines, payments, taxes, client, device and the delivery address — you already received those in order.completed; match by orderId / externalOrderId and apply the change. 
{
  "event": {
    "id": "7f3c2a1b-9d4e-4f6a-8b2c-1e5d3a7f9c0b",
    "type": "order.status_updated",
    "createdAt": "2026-06-10T18:24:31.000Z"
  },
  "data": {
    "orderId": "443bb714-fb69-4538-9ecb-de0acad7b88f",
    "orderCode": "OC-br-001",
    "externalOrderId": "f3bf9fa1-baa8-4050-9e37-4e6d905ee308",
    "businessDayDate": "2026-05-25",
    "status": "COMPLETED",
    "channel": { "code": "99", "uid": "6bac8d41-..." },
    "store": {
      "code": "BR-SP-001",
      "name": "Lab Store BR",
      "account": { "uid": "100", "name": "Sandbox" },
      "vendor":  { "uid": "100.2.1", "name": "Deli Burger BR" }
    },
    "fulfillment": { "service": { "code": "DELIVERY" } },
    "kitchen": {
      "status": "ready",
      "previousStatus": "preparing",
      "rank": 2,
      "occurredAt": "2026-06-10T18:24:29.000Z",
      "stationName": "Hot kitchen",
      "providerEventId": "kds-evt-8842",
      "kdsEventLogId": "1a2b3c4d-...",
      "source": "kds",
      "history": [
        { "status": "preparing", "rank": 1, "occurredAt": "2026-06-10T18:12:02.000Z", "stationName": "Hot kitchen" },
        { "status": "ready",     "rank": 2, "occurredAt": "2026-06-10T18:24:29.000Z", "stationName": "Hot kitchen" }
      ]
    }
  }
}

​
Identity & context

​
orderId
string
Fire’s order UUID — match against the order.completed you received.
​
orderCode
string
Human-readable order code.
​
externalOrderId
string
The order’s id in the channel/aggregator — use it to match on their side.
​
status
string
Business status of the order (COMPLETED / CANCELLED). Context — the kitchen journey is parallel.
​
channel
object
code (canonical, always present — e.g. 99) and uid. The human-readable channel name comes from your channel catalog, not from this event.
​
store
object
Minimal store ref: code, name, plus account { uid, name } and vendor { uid, name }.
​
fulfillment
object
service.code — DELIVERY or PICKUP. Gives the status its meaning (a ready for delivery vs pickup).

​
The kitchen block

​
kitchen
object
The advance that fired the event + the full journey. Distinct from the kds block (static order info captured at injection).

​
Typical use cases

  • Customer order tracking — “your order is ready” on the app or pickup screen
  • Notify the aggregator — tell iFood/Rappi/99food the order is ready for the courier
  • Kitchen metrics — preparing→ready times per store/station from history

​
What it does NOT do

  • It does not change the order status. data.status remains "COMPLETED" — the kitchen journey is parallel to the payment/invoicing lifecycle.
  • It never goes backwards. If the KDS reports ready after dispatched, Fire discards it (anti-regression gate) and emits nothing.
  • It does not replace order.completed. Subscribe to both: order.completed for the business fact, order.status_updated for physical progress.