How it works

An order’s journey

  Customer              Ordering             Our middleware                    Your POS
    │                   platform
    │  places                │                        │                            │
    ├──── the order ────────►│                        │                            │
    │                        │   order webhook        │                            │
    │                        ├───────────────────────►│                            │
    │                        │                        │ ① we record the order      │
    │                        │                        │   (receivedTime)           │
    │                        │                        │                            │
    │                        │                        │ ② we transform it into the │
    │                        │                        │   format in these docs     │
    │                        │                        │                            │
    │                        │                        │ ③ POST to your endpoint    │
    │                        │                        ├───────────────────────────►│
    │                        │                        │                            │
    │                        │                        │◄──── your response ────────┤
    │                        │                        │   (executedTime)           │
    │                        │                        │                            │
    │                        │                        │ ④ we store the request,    │
    │                        │                        │   the response and errors  │

Steps ① – ④ normally take under two seconds. Everything stored at step ④ is what you later see in order lookup.

What happens when your endpoint does not answer

The default is a single attempt: if the call fails, the order does not reach you and stays recorded on our side as undelivered.

If you enable retry, we try several times with growing pauses. Every attempt — successful or not — is visible in the order’s trace.

An internal “executed” status is not proof of delivery

The order carries an internal status of its own, which is not a confirmation that it reached you. The only proof is a 2xx response from your endpoint. That is why order lookup shows the verdict separately from the status — see order lookup.

A menu update’s journey

A full menu update travels the other way and is asynchronous, in two stages:

  Your POS                          Our middleware
      │                                     │
      │  ① POST /api/v3/menu/upload         │
      ├────────────────────────────────────►│
      │                                     │
      │◄──── transaction_id ────────────────┤   "received, will process"
      │                                     │
      │  ② GET /api/v3/menu/checkstatus/... │
      ├────────────────────────────────────►│
      │◄──── final status ──────────────────┤   SUCCESS / ERROR

A success response at step ① means only that the payload was received, not that the menu is updated. The real outcome is read at step ②, or reaches you on its own if you have defined a menu update result endpoint.

Details: full menu update.

Who identifies what

Identifier	Who chooses it	Where it shows up
partner_name	assigned to you at portal registration	in the menu payload, as the prefix in store_id
store_id (LID)	you, when creating the location	in every order and every store operation
order_code	the system, when the order is placed	in the order; it is the key you search by later

The full store identifier format is partner_name__store_id — see terminology.