Core concepts

Order lifecycle

Status flow from inProgress to completed, rejected or cancelled.

Order status flow

stateDiagram-v2
    [*] --> inProgress: receipt, version 1
    inProgress --> accepted: restaurant accepts
    inProgress --> rejected: restaurant rejects
    accepted --> ready
    ready --> completed
    accepted --> completed: ready may be skipped
    inProgress --> cancelled
    accepted --> cancelled
    ready --> cancelled
    completed --> [*]
    rejected --> [*]
    cancelled --> [*]

    classDef ok
    classDef fehler
    class completed ok
    class rejected fehler
    class cancelled fehler

A typical order from your side, with the events you receive:

A typical order

sequenceDiagram
    autonumber
    participant P as Partner
    participant A as Partner API
    participant T as Restaurant till
    P->>A: POST /orders
    A-->>P: 201 inProgress (version 1)
    A->>T: new online order rings
    T->>A: accepted, pickup time set
    A-)P: webhook order.accepted (version 2)
    T->>A: ready
    A-)P: webhook order.ready (version 3)
    T->>A: completed
    A-)P: webhook order.completed (version 4)
    Note over P,A: Every event is delivered at least once.<br/>Apply only a higher version than the last one you applied.

completed, rejected and cancelled are final.
The receipt is version 1. Every status change raises version by 1; use it to order the events of one order.
When two changes happen at once (two till devices, or the restaurant and your cancel), exactly one wins, and only that one produces an event.