Uitverkocht-log en ochtenddigest

Elke keer dat een gerecht uitverkocht raakt — gesnoozed door het team, uitverkocht via voorraad of uitgeschakeld door je kassa — stuurt storekit een event. Dit recept slaat ze op, laat je patronen zien (welke gerechten, welke dagen, welk tijdstip) en post elke ochtend een digest naar Slack, zodat de inkoper en de chef-kok de dag beginnen met de wetenschap wat er op is.

Het dashboard heeft al een snooze-rapport onder Reports (zie Snooze-rapportage). Bouw dit recept wanneer je ook voorraaduitverkopen en kassa-gedreven wijzigingen in dezelfde lijst wilt, of de digest gepusht wil krijgen naar Slack in plaats van hem op te zoeken.

Hoe het werkt

storekit stuurt item.out_of_stock naar je app zodra een item onbeschikbaar wordt.
Je app registreert het item, het tijdstip, de reden en wat het veroorzaakte.
Een geplande taak draait elke ochtend op een door jou gekozen tijdstip en post de lijst van gisteren, plus een rollende “meest uitverkocht deze maand”-tabel, naar Slack.

Wat je nodig hebt

Webhooks ingeschakeld op je storekit-abonnement (Settings → Developers).
Een Replit-account. Dit recept heeft een publieke URL nodig die online blijft, een database en een scheduler voor de ochtendtaak — allemaal biedt Replit op één plek.
Een Slack incoming webhook-URL voor het kanaal dat de digest moet ontvangen.

Stap 1: bouw de app

Plak het hele blok in de builder in één bericht.

Build with Lovable

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.

Volledige prompt (klik om uit te klappen)

I want a small web app that keeps a log of every menu item that goes out of stock at my restaurant, and sends a short digest to Slack every morning. storekit tells the app about stock-outs by webhook. The app must never lose an event, never count the same event twice, and never make storekit wait.

Build it with a database so the log survives restarts, an always-on public HTTPS URL, and a scheduled job for the digest.

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 has the shape { "event": "<event type>", "data": { ... } }. Two exceptions: the legacy order.created event (do not use it; use order.created.v2) sends the bare order object, and the order.refund.created / order.refund.succeeded / order.refund.failed events put order, customer, venue and refund next to event instead of inside 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 is only present for in-store orders; deliveryAddress and pickUpTime only for delivery orders. When they do not apply the key is omitted, so treat a missing key the same as null. notes and items[].note can be null or empty. customer.companyName and customer.vatNumber appear only when supplied.

Example order.created.v2 payload:

{
  "event": "order.created.v2",
  "data": {
    "id": "ord_abc123",
    "code": "A1B2",
    "asap": true,
    "total": 2500,
    "tip": 250,
    "deliveryFee": 299,
    "discountTotal": 0,
    "orderType": "Delivery",
    "pickUpTime": "2024-01-15T10:45:00Z",
    "channel": "WEB",
    "poNumber": null,
    "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",
        "printName": "Margherita",
        "price": 1200,
        "quantity": 1,
        "plu": null,
        "posId": null,
        "taxRate": 20,
        "note": null,
        "modifiers": [
          { "name": "Extra cheese", "printName": "Cheese", "price": 150, "quantity": 1, "plu": null, "posId": null, "taxRate": 20 }
        ]
      }
    ],
    "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 }
      }
    },
    "deliveryAddress": {
      "street1": "456 Oak Ave",
      "street2": "Flat 2",
      "city": "London",
      "postCode": "E1 6AN",
      "country": "UK",
      "notes": null,
      "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

THE EVENT THIS APP USES: item.out_of_stock

Ignore the order example above; this app only cares about item.out_of_stock, which looks like this:

{
  "event": "item.out_of_stock",
  "data": {
    "venue": { "id": 1234, "name": "My Restaurant" },
    "item": { "id": 5678, "name": "Margherita Pizza", "plu": "PLU-001", "posId": "pos_item_42", "sku": "SKU-MARG-001" },
    "reason": "snoozed",
    "source": "manual",
    "details": { "snoozeEnd": "2024-01-15T18:00:00Z" }
  }
}

- reason is one of: snoozed (temporarily hidden by staff), inventory_depleted (sold out through inventory counts), disabled (switched off).
- source is one of: manual (someone in the dashboard), order (a customer order used the last one), deliverect, lightspeed, zonal, pos_sync (pushed from a till or integration).
- details.snoozeEnd is only present for reason snoozed and can be null, meaning snoozed indefinitely.
- plu, posId and sku can be null.
- There is no "back in stock" event. The app records when things went out; it cannot know when they came back.

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. Ignore any svix-id already saved. Handle item.out_of_stock; save and acknowledge any other event type but do nothing with it.
2. A log table with: received time (store UTC, display in TIMEZONE), venue name, item name, item id, plu, sku, reason, source, snoozeEnd. Record the event's time as the time the webhook arrived.
3. GET / — protected by HTTP basic auth with ADMIN_PASSWORD. Three things on one page:
   a. "Yesterday and today": a list of stock-outs since the start of yesterday in TIMEZONE, newest first, showing time, item, reason and source in plain words ("Snoozed by staff until 18:00", "Sold out through inventory after an order", "Switched off from Zonal").
   b. "Most sold out, last 30 days": items ranked by number of stock-outs, with the count and the most common hour of day it happens.
   c. Filters for venue (if I have more than one), reason and a date range, and a Download CSV button that exports whatever is filtered with the columns from point 2.
4. A daily digest posted to Slack via SLACK_WEBHOOK_URL at DIGEST_TIME (HH:MM in TIMEZONE, default 07:30). Content, in Slack mrkdwn:
   *Sold out yesterday — <venue name>, <date>*
   One line per item, in time order: "14:20  Margherita Pizza — sold out (inventory)" or "18:05  Sea Bass — snoozed by staff until 21:00". Group by venue if there is more than one.
   Then a blank line and "*Most sold out this month*" followed by the top five items with counts.
   If nothing sold out yesterday, post "Nothing sold out yesterday." — still post, so I know the app is alive.
   Post the digest once per day even if the app restarts: record the date of the last digest sent and skip if it has already been sent for that date.
5. A "Send digest now" button on the page for testing, which posts the digest for yesterday regardless of whether it was already sent.
6. GET /health that returns 200 and { "ok": true } and nothing else.

Use TIMEZONE for every day boundary and displayed time. Do not guess a default: if TIMEZONE is unset, refuse to start and log a clear message.

DEFINITION OF DONE

- [ ] A signed item.out_of_stock event appears in the log within a second and the endpoint returned 200.
- [ ] The same event delivered twice creates one row.
- [ ] A bad signature returns 400 and logs nothing.
- [ ] The example payload above shows as "Margherita Pizza — snoozed by staff until 18:00".
- [ ] The digest posts at DIGEST_TIME and not again that day, including after a restart.
- [ ] "Send digest now" posts to Slack immediately.
- [ ] The CSV download opens in a spreadsheet with one row per event and the columns listed.
- [ ] Restarting the app loses nothing.

WHAT TO GIVE ME WHEN YOU ARE DONE

1. The public webhook URL (…/webhooks/storekit) and the page URL.
2. The environment variables to set (STOREKIT_WEBHOOK_SECRET, ADMIN_PASSWORD, SLACK_WEBHOOK_URL, TIMEZONE, DIGEST_TIME) and where to set them on this platform.
3. Confirmation that the app stays up 24 hours a day and that the scheduled job runs when nobody has the page open.

Open de app, druk op “Send digest now” en controleer dat Slack “Nothing sold out yesterday.” toont voordat je storekit aansluit.

Stap 2: sluit storekit aan

Open the webhooks portal

In the dashboard sidebar, go to Settings → Webhooks. If your plan includes webhooks and they are not yet enabled, click Enable Webhooks. If the page shows Upgrade to enable webhooks, contact support to discuss adding webhooks to your plan.

Add your app as an endpoint

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.

Copy the signing secret into your app

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.

Send a test event

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.

Vink voor dit endpoint alleen item.out_of_stock aan.

Stap 3: test met een echte uitverkoop

Snooze een item in de menubuilder (zie Producten snoozen). Binnen een paar seconden verschijnt een rij in de app met reden “snoozed” en source “manual”. Un-snooze het item daarna — de app registreert dit niet, wat de bedoeling is.

Ideeën

Wekelijkse inkoop-e-mail: vraag de builder om een maandag-e-mail toe te voegen (via een provider zoals Resend of Postmark) met de 30-dagentabel als CSV bijgevoegd.
Preplijst: markeer items die drie keer in een week vóór 20:00 uitverkocht raken als “onder-geprepareerd” en toon ze apart.
Kruiscontrole met de kassa: filter op source om te zien hoe vaak je POS items verbergt waarvan je dacht dat ze in de verkoop waren.

Wat dit niet doet

Het kan je niet vertellen wanneer een item terugkwam, omdat er geen “terug op voorraad”-event is. Lees het log als “raakte op op”, niet als “was op gedurende”.
Het wijzigt de beschikbaarheid niet. Un-snoozen en bijvullen gebeurt zoals eerst in het dashboard of je kassa.
Events starten vanaf het moment dat je het endpoint verbindt. Er is geen geschiedenis van daarvóór; de 30-dagentabel vult zich in de eerste maand.
Het is jouw service. storekit-support kan bevestigen dat een item.out_of_stock-event je URL heeft bereikt en de responscode; het log en de digest zijn van jou.

Gerelateerd

item.out_of_stock-payload

Elke reason- en source-waarde die het event kan bevatten.

Een prompt schrijven die werkt

De structuur achter deze prompt, en wat te zeggen als de builder het verkeerd doet.

Order-alerts naar Slack of je telefoon

Hetzelfde patroon voor bestellingen in plaats van voorraad.

Beschikbaarheid en snoozen

Snoozen, voorraad en het ingebouwde snooze-rapport.

​Hoe het werkt

​Wat je nodig hebt

​Stap 1: bouw de app

​Stap 2: sluit storekit aan

​Stap 3: test met een echte uitverkoop

​Ideeën

​Wat dit niet doet

​Gerelateerd

item.out_of_stock-payload

Een prompt schrijven die werkt

Order-alerts naar Slack of je telefoon

Beschikbaarheid en snoozen

Hoe het werkt

Wat je nodig hebt

Stap 1: bouw de app

Stap 2: sluit storekit aan

Stap 3: test met een echte uitverkoop

Ideeën

Wat dit niet doet

Gerelateerd