Webhooks

Delieta does not call your server when an order changes status. The published OpenAPI has no partner webhook operation. There is one signed signal to a shop that runs on @delieta/shop-runtime, and one report the other way.

Refresh signal: POST /api/revalidate

When the owner changes the menu, the shop settings or the floor plan, Delieta calls POST {shop-deployment-address}/api/revalidate. The shop expires its cache and the next request fetches fresh data. The body is {"reason":"menu"|"shop-config"|"floor-plan","at":"…ISO…"}.

POST /api/revalidate
x-delieta-signature: 9f2c…
Content-Type: application/json

{"reason":"menu","at":"2026-11-05T12:00:00.000Z"}

The signature is the x-delieta-signature header: a hex HMAC-SHA256 of the raw body, keyed by that shop's refresh secret (DELIETA_REVALIDATE_SECRET on the shop side). The handler from @delieta/shop-runtime checks the signature in constant time. A bad signature → 401, no secret on the shop → 503, a bad body → 400, success → 204. Delieta waits up to 5 seconds for the answer and ignores a failure: a refresh is a convenience, not a transaction. The shop reads Delieta uncached anyway, so the worst outcome is a delay.

This address is served by the signature, not by an API key. There is no publishable key or partner secret in it.

Shop heartbeat

The other way, a deployed shop reports which runtime it was built with: POST /api/v1/shop-heartbeat. delieta-shop-assert sends this after next build, once per build. Delieta stores the runtime and contract version on the shop row, so it sees which shops need a refresh. Always 204; there is nothing to handle.

Order status: read it with a GET

After POST /api/v1/orders an order can be pending_acceptance. It leaves that state when someone in the kitchen accepts or rejects, or when the timeout passes. Your backend causes none of that, so you read: GET /api/v1/orders/{id} with a secret key, or GET /api/v1/orders/{id}/status by the short code, also with a publishable key. Polling counts towards the read limit and does not use the order-creation limit.

404 not_found means "no such order for this key". An order of another company answers identically.

What is not here

There is no signed POST about a status change to https://your-shop/hooks/orders. There is no partner webhook secret and no retries on our side. Your company's payment for Delieta goes through Stripe and is a matter for the panel, not the Partner API. When partner webhooks arrive, they will appear as a new operation in GET /api/v1/openapi and on the Partner API page.