> ## Documentation Index
> Fetch the complete documentation index at: https://storekit.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Live Order Board for the Pass
> A full-screen order board that shows every open ticket and moves it across New, Accepted, Preparing, Ready and Done as storekit order events arrive.
A wall screen for the pass, the bar or the front counter that shows open orders as cards and moves them along as their status changes in storekit. Big order codes, item lists, a timer that turns red when an order has waited too long, and your own choice of what to show. No one touches it: it follows the dashboard.
storekit has a built-in [Kitchen Display](/docs/guides/orders/kitchen-display) that the kitchen can bump tickets on. Build this recipe when you want a read-only screen with a different layout — a customer-facing "ready" board, a counter view that only shows pickups, or a bar screen that only shows drinks.
## How It Works
1. storekit sends order lifecycle events to your app: `order.created` and `order.accepted` carry the full order; `order.preparing`, `order.ready_for_pickup` and `order.completed` carry just the id, code and new status.
2. Your app keeps one card per order and updates its column from each event.
3. A browser page refreshes itself every few seconds and shows the cards in columns.
## What You Need
* Webhooks enabled on your storekit plan (**Settings** → **Developers**).
* A [Lovable](https://lovable.dev) or [v0](https://v0.dev) account. Both need a backend for the webhook endpoint and a small database — the prompt asks the builder to deploy one and give you its URL. [Replit](https://replit.com) also works.
* A screen with a browser (a TV with a cheap stick, an old iPad or laptop).
## Step 1: Build the App
Paste the whole block into the builder in a single message. Adjust **MY BOARD** first if you want a customer-facing or drinks-only variant.
Either button opens the builder with the whole prompt below already filled in. Nothing starts until you press send, so read it through and edit the parts marked as yours first.
```text theme={null}
I want a live order board for my restaurant: a full-screen web page that shows open orders as cards in columns and moves them along as storekit tells it about status changes. Nobody interacts with the board; it just stays accurate. storekit sends the status changes as webhooks.
Build it with a backend that has a public HTTPS URL for the webhook (deploy it and tell me the URL), a small database for the current orders, and a front end designed for a TV.
```
```text theme={null}
CONTEXT ABOUT STOREKIT
I run a hospitality business on storekit (storekit.com), an online ordering and payments platform for restaurants, cafés and bars. storekit can notify my own app about things that happen in my store by sending webhooks.
How storekit webhooks work:
- Each event is an HTTP POST with a JSON body to a URL I register in the storekit dashboard.
- The body always has the shape { "event": "", "data": { ... } }.
- Requests are signed with Svix. Every request carries the headers svix-id, svix-timestamp and svix-signature. Verify them with the official `svix` library for your language, using a secret I will provide in an environment variable called STOREKIT_WEBHOOK_SECRET. Reject anything that fails verification with HTTP 400.
- My endpoint must respond with a 2xx status within 15 seconds. Save the event to the database first, respond 200, then do the work from the saved copy.
- Once I have responded 200, storekit will not send that event again, so the work must not be lost: store each event with a status (pending, done, failed) and only mark it done after the work has actually succeeded. On startup and on a timer, pick up anything still pending or failed and retry it. Never do the work only in memory after responding.
- The same event can occasionally be delivered more than once. Use the svix-id header as the unique key for the saved event: a repeat of an event already saved is ignored, whatever its status.
- Any page or endpoint protected by a password must be served over HTTPS only; redirect or refuse plain HTTP.
- Money fields (total, tip, deliveryFee, discountTotal, item price, modifier price) are integers in minor units: 2500 means £25.00.
- orderType is one of Delivery, Pickup, InStore, Curbside, CateringDelivery, CateringPickup or Billpay.
- table and deliveryAddress can be null. notes can be null or empty.
Example order.created payload:
{
"event": "order.created",
"data": {
"id": "ord_abc123",
"code": "A1B2",
"asap": true,
"total": 2500,
"tip": 250,
"deliveryFee": 299,
"discountTotal": 0,
"orderType": "Pickup",
"createdAt": "2024-01-15T10:30:00Z",
"deliveryTime": "2024-01-15T11:00:00Z",
"notes": "Ring doorbell",
"customer": {
"firstName": "John",
"lastName": "Doe",
"email": "john@example.com",
"phone": "+44123456789",
"marketingConsent": true
},
"items": [
{
"name": "Margherita Pizza",
"price": 1200,
"quantity": 1,
"plu": null,
"posId": null,
"taxRate": null,
"modifiers": []
}
],
"venue": {
"id": 1234,
"name": "My Restaurant",
"slug": "my-restaurant",
"address": {
"street1": "123 Main St",
"street2": "",
"city": "London",
"postCode": "W1A 1AA",
"country": "UK",
"companyName": "My Restaurant Ltd",
"coordinates": { "latitude": 51.5074, "longitude": -0.1278 }
}
},
"table": {
"id": "tbl_123",
"name": "Table 5",
"covers": 4,
"posId": "pos_tbl_5",
"area": { "id": "area_1", "name": "Main Floor", "posId": null }
},
"deliveryAddress": {
"street1": "456 Oak Ave",
"street2": "Flat 2",
"city": "London",
"postCode": "E1 6AN",
"country": "UK",
"coordinates": { "latitude": 51.5155, "longitude": -0.0722 }
}
}
}
The full list of event types and payloads is at https://storekit.com/docs/developers/webhooks/webhook-events
```
```text theme={null}
THE STATUS EVENTS
Besides order.created, storekit sends these events for the same order as it moves through the kitchen. order.accepted has the same full payload as order.created. order.preparing, order.ready_for_pickup and order.completed have a smaller payload:
{
"event": "order.preparing",
"data": {
"order": { "id": "ord_abc123", "code": "A1B2", "status": "preparing" },
"venue": { "id": 1234, "name": "My Restaurant", "slug": "my-restaurant" }
}
}
So the order id is data.id for the full payload and data.order.id for the smaller one. Write one function that returns the id and code from either shape. Also accept order.rejected, order.canceled and order.out_for_delivery: read the id from whichever of data.id or data.order.id is present, and treat rejected and canceled as "remove from board", out_for_delivery as "Done".
Events can arrive out of order or twice. Store a rank per status (created 0, accepted 1, preparing 2, ready_for_pickup 3, out_for_delivery 4, completed 4, rejected/canceled 9) and never move a card to a lower rank than it already has.
WHAT TO BUILD
1. POST /webhooks/storekit — verify the Svix signature with the official svix library and STOREKIT_WEBHOOK_SECRET against the raw request body; 400 on failure. Save the event and return 200 immediately; update the board state afterwards. Ignore any svix-id already saved.
2. An orders table keyed by storekit order id with: code, status, rank, orderType, table name (or null), customer first name, items (name, quantity, modifiers names, notes), order notes, createdAt, deliveryTime, venue name, last updated. Full payloads (created, accepted) fill or refresh every field; small payloads update only status, rank and last updated. If a small payload arrives for an order the board has never seen, create a card with just the code and status so it is not lost.
3. GET /board/ — the full-screen page, where BOARD_TOKEN is a long random secret from an environment variable. There is no login because it runs on a screen behind the counter, so the token in the URL is the only thing keeping strangers out: any request to /board or /api/board without the exact token gets 404 and nothing else, and the token must never appear in logs or error pages. Below I write /board for short; always include the token segment. The page must not include customer surname, phone, email or delivery address anywhere in the page or its data requests. Columns, left to right: New (created), Accepted, Preparing, Ready (ready_for_pickup), Done (completed, out_for_delivery). Cards show: the order code very large, orderType and table name, the customer's first name, the item list as "2 × Margherita Pizza" with modifiers indented and notes in italics, and a timer showing minutes since createdAt. Cards are ordered oldest first inside each column. Cards in Done disappear DONE_MINUTES after they entered Done (default 10). Cards for rejected or canceled orders disappear immediately.
4. The page refreshes its data every 5 seconds without flicker (fetch JSON from GET /api/board/ and re-render, or use server-sent events). If a refresh fails, keep showing the last data and show a small "reconnecting" label; never show a blank board.
5. Timer colours: default until WARN_MINUTES (default 10), amber until LATE_MINUTES (default 20), red after. For orders with a deliveryTime in the future, count down to deliveryTime instead and label it "for 11:00".
6. Design for a 1080p TV viewed from three metres: dark background, minimum 28px body text, order codes at least 96px, no hover-only information, no scrollbars — if a column overflows, shrink cards gracefully and show "+N more" at the bottom.
7. Filters via query string so I can point different screens at different views: ?types=Pickup,Delivery shows only those orderTypes; ?columns=Ready shows only that column with much bigger cards for a customer-facing "ready to collect" screen; ?venue= if the account has more than one venue.
8. GET /health that returns 200 and { "ok": true } and nothing else. Every other route must be either /board/, /api/board/ or the webhook.
MY BOARD
- Timezone: TIMEZONE environment variable; show all times in it.
- Show the item list on cards: yes.
- Customer-facing variant I will run on a second screen: /board/?columns=Ready.
DEFINITION OF DONE
- [ ] A signed order.created creates a card in New within 5 seconds, showing the code, items and a running timer.
- [ ] order.accepted, order.preparing, order.ready_for_pickup, order.completed for the same id move the card one column at a time, and it disappears DONE_MINUTES after completed.
- [ ] Receiving order.preparing before order.accepted leaves the card in Preparing (it never goes backwards).
- [ ] The same event delivered twice changes nothing the second time.
- [ ] A bad signature returns 400 and the board does not change.
- [ ] order.canceled removes the card immediately.
- [ ] /board/?columns=Ready shows only Ready cards, large, with no item list.
- [ ] /board and /api/board with a missing or wrong token return 404.
- [ ] Neither the HTML nor the JSON contains an email address, phone number, surname or delivery address.
- [ ] Turning the backend off and on loses no cards.
WHAT TO GIVE ME WHEN YOU ARE DONE
1. The public webhook URL (…/webhooks/storekit) and the full /board URL including the token.
2. The environment variables to set (STOREKIT_WEBHOOK_SECRET, BOARD_TOKEN, TIMEZONE, optionally DONE_MINUTES, WARN_MINUTES, LATE_MINUTES) and where to set them on this platform.
3. Confirmation that the backend stays up 24 hours a day and does not sleep between requests.
4. How to open the board in full-screen mode on a TV browser.
```
## Step 2: Connect storekit
In the dashboard sidebar, go to **Settings** → **Developers** and click **Manage Webhooks** (it reads **Enable Webhooks** the first time). Webhooks are a subscription feature — if you see **Upgrade to enable webhooks**, [contact support](/docs/getting-started/contact-support) first.
In the embedded portal, add a new endpoint, paste the webhook URL your app builder gave you, and tick only the event types the recipe needs.
Open the endpoint you just created and copy its signing secret. In your app builder, save it as the environment variable `STOREKIT_WEBHOOK_SECRET` (builders call this "secrets" or "environment variables"). Redeploy if the builder asks you to.
Use the portal's test option on the endpoint to send a sample event. The delivery log shows the response code from your app. A `2xx` means your app accepted it; anything else, read the response body in the log — it is usually a missing secret.
Tick `order.created`, `order.accepted`, `order.preparing`, `order.ready_for_pickup`, `order.out_for_delivery`, `order.completed`, `order.rejected` and `order.canceled` for this endpoint.
## Step 3: Test With a Real Order
Open the board URL (with its token) on the screen, then place an order on your own storefront. The card appears in New; move the order through its statuses in the dashboard (see [Managing Live Orders](/docs/guides/orders/managing-live-orders)) and watch the card follow. Cancel a test order to see it disappear.
If your store auto-accepts orders, the card will skip straight to Accepted, which is correct.
## Ideas
* **Sounds**: a chime when a card enters New, a different one when it enters Ready.
* **Station boards**: tag items by category (the builder can match on item name or `plu`) and show one board per station, like the [custom kitchen ticket](/docs/guides/build/recipes/custom-kitchen-ticket) does on paper.
* **Late-order alert**: when a card turns red, post to Slack using the pattern from [Order Alerts](/docs/guides/build/recipes/order-alerts).
## What This Does Not Do
* **It cannot change an order.** The board is read-only; accepting, marking ready and completing still happen in the dashboard or your till, which is what the built-in [Kitchen Display](/docs/guides/orders/kitchen-display) is for.
* **It only knows what the events say.** `order.rejected`, `order.canceled` and `order.out_for_delivery` are listed in the reference without a sample payload, which is why the prompt asks the builder to accept either shape. If a card does not move on one of them, check the webhook delivery log in the portal to see what was sent.
* **The URL is the key.** Anyone with the full board URL can see live order codes, first names and items, so treat it like a password: do not share it outside the team, and change BOARD\_TOKEN if a screen is lost.
* **It starts empty.** Orders placed before the endpoint was connected will not appear.
* **It is your service.** storekit support can confirm the events reached your URL and the response code; the board is yours.
## Related
Every order lifecycle event and payload.
storekit's built-in bumpable kitchen screen.
What each status means and how orders move between them.
The structure behind this prompt, and what to say when the builder gets it wrong.
## Related topics
- [Build Your Own Tools on storekit](/docs/guides/build/overview.md)
- [Managing Live Orders](/docs/guides/orders/managing-live-orders.md)
- [Orders Overview](/docs/guides/orders/overview.md)
- [Kitchen Display](/docs/guides/orders/kitchen-display.md)
- [Connecting Toast](/docs/guides/integrations/pos/toast/connect.md)
Build with Lovable