Skip to main content
Once a store is connected to Stream, every order placed on it is queued to Stream automatically. Stream passes the order to your POS and reports back on its progress.

How an Order Reaches Stream

  1. The customer completes checkout and the order is created in storekit.
  2. storekit queues the order to Stream — immediately for an ASAP order, or delayed for a pre-order when Buffer Orders is on.
  3. storekit builds the Stream order and sends it. If Stream rejects the request, storekit retries up to six more times over a few seconds.
  4. Stream reports accepted — the order is marked Accepted in storekit and the timeline records the status change from the POS.
  5. Stream reports a status change or a cancellation as the order progresses.
Orders go to Stream as soon as they are placed — there is no accept step in storekit first. Multi-vendor orders are merged into one Stream order before dispatch, so a customer ordering from several vendors at once appears at the POS as a single ticket.

What’s in the Order

Tax is not itemised on the Stream order; prices are sent as they appear on the storekit menu.

Order Notes

Order Note Template on the Stream Integration page controls the note sent with each order. Support can click Insert Variable to see the available variables and Preview to check the result with sample data. The customer’s own notes are appended after the template, separated by a dash. Without a template, the note is the customer’s notes. For in-store orders without a template, storekit prefixes the note with Table <table name> and sends the customer name as <table name> (<customer name>) so the ticket shows where it belongs — see Dine-in.

Pre-Order Buffering

By default a pre-order is sent to Stream straight away, which can clutter the kitchen hours ahead of time. To delay it, ask storekit support to:
  1. Turn on Buffer Orders.
  2. Set Buffer Value — the order is sent that many minutes before the requested fulfilment time. It must be at least 1 (Buffer value must be greater than 0).
With Buffer Orders on and no Buffer Value saved, storekit uses the store’s normal prep-time calculation to decide when to send. Orders without a requested time are never buffered.
15–30 minutes is a good starting point for a busy kitchen.

Updates From Stream

Stream can change the order in storekit after it’s accepted:
  • Status changesready_for_pickup, out_for_delivery and completed from Stream move the order to Ready for Pickup, Out for Delivery or Completed in storekit, and trigger the usual customer notifications for those statuses. Other Stream statuses are ignored.
  • Cancellation from Stream — the order is cancelled in storekit, with the source recorded as Stream.
  • Cancellation from storekit — cancelling an order in the dashboard sends a cancel request to Stream so the POS ticket is voided. Cancellations that originated from Stream aren’t sent back.

When an Order Fails

There are two ways a Stream order can fail:
  • Stream rejects the request. If Stream’s API refuses the order after storekit’s retries, the order is marked Failed and storekit’s team is alerted. No failure reason is stored against the order in this case, so the order page shows only the Failed status.
  • Stream reports a failure. If Stream accepts the request but the POS then fails the order, Stream sends a failure event with a reason. storekit marks the order Failed, stores Stream’s reason word for word against the order, and emails the store.

The Failed-Order Email

The email is sent when Stream reports the failure, with the subject Stream Issue: Order #<order number> for store: <store name> and the failure reason in the body. It goes to the store’s Email address list on Stores → your store → SettingsGeneral — the first address as the recipient, the rest as blind copies. If that list is empty, no email is sent. Where storekit recognises the reason, the email also includes guidance on what to do next.

Resending a Failed Order

Open the order in the dashboard and click More actionsResend order to POS. storekit queues the order to Stream again (respecting the pre-order buffer). The option is only offered while the order has no POS receipt, and the resend is refused with This order has already been sent to the POS. Resending it would create a duplicate POS order. once Stream has accepted the order — even if the POS failed it afterwards. In that case, check the POS rather than resending.

Next Steps

Dine-in

How table orders reach Stream

Troubleshooting

Orders not reaching Stream, or failing once they do