Skip to main content
This page lists all webhook events available in storekit, grouped by category.

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. The data 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 as order.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.
Send a 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.accepted or order.rejected event.
  • 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
The reason field indicates why the item went out of stock, and source indicates what triggered it.
The details object varies by reason:
  • snoozed — includes snoozeEnd (ISO 8601 timestamp, or null for 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. Triggered when a new payment link is created. Only fired for accounts with webhooks enabled.
Triggered when a payment is successfully collected via a payment link. Only fired for accounts with webhooks enabled.
Triggered when a refund is initiated for a payment link payment. The refund is pending at this point — confirmation arrives via payment_link.refund.succeeded or payment_link.refund.failed once the payment gateway processes it asynchronously.
Triggered when the payment gateway confirms a refund has been successfully processed. This fires asynchronously after payment_link.refund.created.
Triggered when the payment gateway rejects a refund. This fires asynchronously after payment_link.refund.created.

Printer Events

Events related to cloud printer status.

printer.status.offline

Triggered when a connected cloud printer fails to check in to the storekit server for 5 minutes. An email notification is also sent to the venue’s configured email address.
A printer shared by several stores sends one event per store.

printer.status.online

Triggered when a cloud printer reconnects to our servers after being offline for at least 5 minutes. An email notification is also sent to confirm the printer is back online.