PHP2Shell: Is Your Joomla Site Safe? What to Do Today Introducing Next Boards: Kanban project and task boards for Joomla Next Exams 6.2.0: Exam Studio, six visual question types, exam embeds and six new languages Building the Future of Joomla Extensions
NextSoftware
Next Restaurant — Documentation

Payload data

The payload

Each delivery is a POST with a JSON body of this shape:

{
  "id": "msg_4e9c1b7a2f08d3516ac4be9017d2f5a3",
  "type": "order.placed",
  "event": "order.placed",
  "data": { },
  "timestamp": "2026-08-28T19:30:00+00:00"
}
Field Meaning
id Unique id for this delivery. Same value as the webhook-id header. Dedupe on it.
type The event name from the table above
event The same name again, kept for integrations built before type existed
data Identifiers for what changed — see below
timestamp ISO 8601, when the event was dispatched

type and event always carry the same value. type is the field name the Standard Webhooks specification uses, so a consumer built on an off-the-shelf library reads it without a mapping step; event is not going anywhere.

What data contains

data is a small set of identifiers, not the whole order. It tells you what changed so you can decide whether to care; it is not a substitute for your own record of the order.

Event data fields
order.placed (storefront, QR or API) id, location_id, channel, source
order.placed / order.updated (created or edited in the admin or POS) id, location_id, channel, status
order.status_changed id, status
order.cancelled id, status, reason, location_id
ping message, at 
{
  "id": "msg_4e9c1b7a2f08d3516ac4be9017d2f5a3",
  "type": "order.placed",
  "event": "order.placed",
  "data": { "id": 580, "location_id": 2, "channel": "web", "source": "api" },
  "timestamp": "2026-09-07T20:42:51+00:00"
}

Two different ids, and they are not interchangeable. data.id is the internal order id and the key to join on. The top-level id identifies the delivery — it is what you dedupe on, and it changes every time even when the order does not.

Note that order.placed carries source when the order came from the storefront, QR ordering or the REST API, and status when it was created in the back office — so read both defensively.

There is no endpoint to fetch an order by id. The REST API covers locations, menu and order creation only. If you need the full contents of an order later, store the response you got when you created it — webhooks tell you an order changed, not what is in it.

Write your consumer to ignore fields it doesn't recognise. New fields are added to payloads over time, and a consumer that rejects unknown keys will break on an upgrade it didn't need to care about.

All Extensions