Order Events
Events related to order lifecycle and management.order.created.v2
Triggered when a new order is placed by a customer. This is the event to subscribe to for new orders.order.accepted
Triggered when the order was accepted in the dashboard, through a signed link, or by a connected POS. This event is sent only when Auto-accept is off; on auto-accept stores,order.created.v2 already means the order was accepted.
Its data contains the same order fields as order.created.v2, built from the stored order, plus status and acceptedAt. It does not include actions.
order.rejected
Triggered when an order is rejected at a store with Auto-accept off. Thedata object contains the same order fields as order.created.v2, built from the stored order, plus status and rejectedAt. It does not include actions.
order.created
The legacy new-order event. It carries the same order fields asorder.created.v2, but sends them as the top-level body with no event or data wrapper:
Both events are sent for every new order. Subscribe to
order.created.v2 so your handler receives the standard payload structure used by every other event. order.created remains available for existing integrations.Accepting or Rejecting an Order From the Webhook
When the store has Auto-accept turned off,order.created.v2 and order.created include an actions object with two links: one accepts the order, the other rejects it. It is in data.actions for order.created.v2 and at the top level for order.created. Stores with Auto-accept on get no actions.
POST to the link, with no body. No API key is needed: the link itself is the credential, so treat it like a password and don’t log or share it. Links only accept POST.
- A successful link call is followed by the matching
order.acceptedororder.rejectedevent. - An order rejected because its payment failed does not send
order.rejected. - Links expire 1 hour after the webhook is sent. A retried delivery carries the original links, so they may already have expired.
- Each order can be accepted or rejected once. After the first successful call, both links return
409. - A link changes the order status the same way the dashboard does. Rejecting from a link does not refund the payment and, unlike the dashboard, does not prompt for a refund: refund the order from the dashboard if needed.
order.canceled
Triggered when an order is canceled.order.preparing
Triggered when an order transitions to the preparing status.order.ready_for_pickup
Triggered when an order is marked as ready for customer pickup.order.out_for_delivery
Triggered when a delivery order is dispatched.order.completed
Triggered when an order is marked as completed. This fires for individual order completions (via the dashboard, Deliverect, iKentoo, or auto-update) as well as bulk completions.order.pos.dispatch.failed
Triggered when an order fails to dispatch to a POS system.order.rating.updated
Triggered when a customer submits or updates a rating for their order.order.refund.created, order.refund.succeeded, order.refund.failed
order.refund.created fires when a refund is issued from the dashboard; order.refund.succeeded or order.refund.failed follows once the payment gateway processes it. All three share one shape, and unlike other events the fields sit alongside event rather than inside data:
customer.id and refund.reason are null when not available.
Store Events
Events related to store status and configuration.store.opened
Triggered when a store is opened, when a snooze is ended early, or when a timed snooze expires automatically.store.closed
Triggered when a store is closed or snoozed.closedReason and closedUntil are empty strings when the store was closed without a reason or an end time.
store.opening_hours.updated
Triggered when opening hours are changed for a store, from the dashboard or by a POS sync.Item Events
Events related to menu item availability.item.out_of_stock
Triggered when a menu item becomes unavailable. This can happen through several paths:- Manual snooze — an admin snoozes the item from the dashboard
- Manual disable — an admin sets the item’s availability to off
- Inventory depletion — the item’s inventory reaches zero after an order
- Integration sync — a POS or integration (Deliverect, Lightspeed, Zonal) marks the item as unavailable
reason field indicates why the item went out of stock, and source indicates what triggered it.
details object varies by reason:
snoozed— includessnoozeEnd(ISO 8601 timestamp, ornullfor indefinite snoozes)inventory_depleted— empty{}disabled— empty{}
Payments Events
Events related to payments and payouts.payments.payout.created
Triggered when storekit sends a payout to your bank account.estimatedArrivalDate is a month/year string, or an empty string when the payout provider did not supply one.
payment_link.created
Triggered when a new payment link is created. Only fired for accounts with webhooks enabled.payment_link.paid
Triggered when a payment is successfully collected via a payment link. Only fired for accounts with webhooks enabled.payment_link.refund.created
Triggered when a refund is initiated for a payment link payment. The refund is pending at this point — confirmation arrives viapayment_link.refund.succeeded or payment_link.refund.failed once the payment gateway processes it asynchronously.
payment_link.refund.succeeded
Triggered when the payment gateway confirms a refund has been successfully processed. This fires asynchronously afterpayment_link.refund.created.
payment_link.refund.failed
Triggered when the payment gateway rejects a refund. This fires asynchronously afterpayment_link.refund.created.