Order rejected
An order was rejected, including the automatic rejections OneTablet makes at intake.
Delivered to the ONE url you registered for orders.
Request
- idstring
Unique event id — the deduplication key.
Deliveries are at-least-once and unordered, so you WILL receive the same event more than once. Every copy of one event carries the same
id: retries of a delivery, and the deliveries to each url you have registered. Two legitimate transitions of the same subject are two different events and carry two different ids.Key your idempotency on this field alone. Nothing else in the payload is a dedup key —
timestampis the moment the attempt was SENT and differs between copies of one event. - eventstring
Always
order.rejected.Possible values: [order.rejected] - timestampstring<date-time>
When this delivery was SENT — not when the event happened. Order by the transported state, never by arrival.
- organization_idstring
Your organization id, also carried on the delivery's
X-Organization-IDheader.Snake case on this ONE field is a long-lived wire value; every other field on this API is camelCase.
Treat it as a sanity check, never as proof of origin — it is a value inside a body anyone who learns your url can POST. Proof of origin is the
X-OneTablet-Signatureheader, which store-event deliveries carry on every attempt; see "Verifying webhook signatures". Phase 0 order deliveries are not signed yet, so for those there is no cryptographic authentication at all. - dataOrder
The order, with
status: rejected.
{
"id": "00000000-0000-0000-0000-000000000000",
"event": "order.rejected",
"timestamp": "2026-01-01T00:00:00Z",
"organization_id": "00000000-0000-0000-0000-000000000000",
"data": {
"id": "00000000-0000-0000-0000-000000000000",
"status": "new",
"deliveryStatus": "ASSIGNED",
"createdAt": "2026-01-01T00:00:00Z",
"updatedAt": "2026-01-01T00:00:00Z"
}
}About Orders
Orders placed with your restaurants — read them, and act on them.
This is where an integration starts: poll fetchOrders for the orders OneTablet has accepted on your behalf across every delivery platform you are connected to, normalised into ONE shape regardless of whether they arrived from DoorDash, Uber Eats, Grubhub or a direct channel.
Two conventions hold everywhere on this API and are worth learning once. Money is always an integer in the currency's minor unit — 1250 is $12.50 — because a decimal total cannot survive a round trip through every language's default number type. Times are always ISO-8601 in UTC; a store's local time is a rendering decision, and the API does not make it for you.
All endpoints are POST with a single JSON body, and the path carries no version segment: evolution here is additive — new fields and new endpoints, never removals or narrowing — so there is no cutover a /v1 would ever mark.