Qashier Open API (2026-10-31)

Every store this credential can reach. Lets a partner discover store ids instead of being sent a list by email, which goes stale the first time the merchant opens an outlet.

The catalogue a partner builds its menu from: per-store price, modifiers, variants, SKUs and the track-inventory flag. duplicateSku marks a SKU that matches more than one product, because such a line becomes a custom item with no stock movement and the partner should see that here rather than as stock drift later.

Current quantity per SKU. This is also the daily reconciliation path: webhook delivery is at-least-once and unordered, so a partner that missed events converges by pulling this.

Creates the transaction already paid, in one call. Qashier recomputes the total from the store's own tax, service-charge and rounding settings and rejects the order if it differs from amountCharged — nothing is persisted, deducted or printed on a rejection. X-Idempotency-Key is required; send the partner order id.

What we stored, keyed by the transactionId the create answered with. Needed for partner-side reconciliation and so support can answer a question without a Qashier login.

Keep that id against your own order. If you lose it, replay the create with the same X-Idempotency-Key — a replay returns the original order rather than creating a second one, so the id comes back. ORDER_NOT_FOUND also answers a transaction belonging to another client, so this read cannot be used to discover whether an id exists elsewhere.

This is also where a cancellation in progress is visible. A cancellation reverses several things and finalizes only when all of them are done, and the refund leg of an order paid on your own gateway waits for a cashier — so status: CANCELLING with per-task detail in cancellation.tasks is the normal path, not a rare window. transaction.cancelled is delivered when the cancellation finalizes, so poll this to see where a cancellation has got to before then.

Fires for every stock movement in a store whose credential has a webhook URL, whatever caused it: a sale through this API, a sale on the POS, a restock or adjustment in HQ, a stock take, a transfer, or a cancellation putting quantities back. reason says which. A product that does not track inventory never produces one, and neither does a custom line whose SKU matched nothing.

Ordering. Two events for the same SKU can arrive in either order. quantityChange is what moved and resultingBalance is the quantity after it moved, so never apply quantityChange as a delta — but an absolute value does not make order irrelevant: if you store whatever arrives last, a reversed pair leaves you on the older number. Keep the occurredAt you last applied per SKU and drop any event whose occurredAt is earlier. Compare occurredAt (when stock moved), not createdAt (when we emitted the event).

If you miss events, GET /stores/{storeId}/stock is the recovery path and the daily reconciliation path. It is the authority; a webhook is a notification.

Delivery is at-least-once and unordered. Dedupe on eventId, which is stable across every retry of the same event. Order between different events is not guaranteed either; what that means for you is specific to the event and described above.

Retries. An attempt that does not return 2xx is retried with exponential backoff and equal jitter: the window doubles from 10 seconds to a ceiling of 1 hour, and each attempt fires at a random point in the second half of its window, so a fleet of failed deliveries does not return as a thundering herd. We give up after 30 attempts or 24 hours, whichever comes first.

Sustained failure. After 20 consecutive failures across all events we pause delivery for your credential and probe every 5 minutes; two successful probes resume it. Queued events are not discarded while paused — they drain once delivery resumes, subject to the 24-hour limit above.

Fires when a cancellation finalizes, not when staff start one. A cancellation reverses several things — stock, the refund leg, loyalty, a table session — and finalizes once every one of them is terminal; until then the order reads status: CANCELLING on GET /orders/{transactionId} with a task breakdown. Because Qashier never held the money for your orders, the refund leg waits for a cashier to record how it was returned, so expect a gap between the staff action and this event rather than treating it as immediate.

It reports that the order is cancelled in Qashier and what staff recorded as refunded, which may be 0 — it does not move money. Refunding the customer is yours to do on the gateway that took the payment. Each restored line also produces an inventory.changed with reason: CANCELLATION_RESTORE.

outcome says whether every reversal succeeded. COMPLETED_WITH_FAILURES means the order is cancelled but at least one reversal did not go through and staff have to finish it by hand — read the order back for cancellation.tasks to see which.

Ordering. One order cancels once, so there is nothing to order between deliveries of this event. It can arrive before or after the inventory.changed events for the same cancellation; neither implies the other has been delivered.

If you miss it, GET /orders/{transactionId} shows status: CANCELLED and the cancellation block with the same outcome. That read is the authority; this event is a notification.

Delivery is at-least-once and unordered. Dedupe on eventId, which is stable across every retry of the same event. Order between different events is not guaranteed either; what that means for you is specific to the event and described above.

Retries. An attempt that does not return 2xx is retried with exponential backoff and equal jitter: the window doubles from 10 seconds to a ceiling of 1 hour, and each attempt fires at a random point in the second half of its window, so a fleet of failed deliveries does not return as a thundering herd. We give up after 30 attempts or 24 hours, whichever comes first.

Sustained failure. After 20 consecutive failures across all events we pause delivery for your credential and probe every 5 minutes; two successful probes resume it. Queued events are not discarded while paused — they drain once delivery resumes, subject to the 24-hour limit above.