Out-of-Stock Log and Morning Digest

Every time a dish goes out of stock — snoozed by the team, sold out through inventory, or switched off by your till — storekit sends an event. This recipe stores them, shows you patterns (which dishes, which days, what time) and posts a digest to Slack every morning so the buyer and the head chef start the day knowing what ran out.

The dashboard already has a snooze report under Reports (see Snooze Reporting). Build this recipe when you also want inventory sell-outs and till-driven changes in the same list, or want the digest pushed to Slack rather than looked up.

How It Works

storekit sends item.out_of_stock to your app whenever an item becomes unavailable.
Your app records the item, the time, the reason and what caused it.
A scheduled job runs at a time you choose each morning and posts yesterday’s list, plus a rolling “most sold out this month” table, to Slack.

What You Need

Webhooks enabled on your storekit plan (Settings → Developers).
A Replit account. This recipe needs a public URL that stays up, a database, and a scheduler for the morning job, which Replit provides in one place.
A Slack incoming webhook URL for the channel that should receive the digest.

Step 1: Build the App

Paste the whole block into the builder in a single message.

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.

Full prompt (click to expand)

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 always has the shape { "event": "<event type>", "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

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 the app, press “Send digest now”, and check Slack shows “Nothing sold out yesterday.” before connecting storekit.

Step 2: Connect storekit

Open the webhooks portal

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 first.

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.

Tick only item.out_of_stock for this endpoint.

Step 3: Test With a Real Stock-Out

Snooze an item in the menu builder (see Snoozing Products). Within a few seconds a row appears in the app with reason “snoozed” and source “manual”. Unsnooze the item afterwards — the app does not record this, which is expected.

Ideas

Weekly buyer email: ask the builder to add a Monday email (via a provider such as Resend or Postmark) with the 30-day table attached as CSV.
Prep list: mark items that sell out before 8 pm three times in a week as “under-prepped” and list them separately.
Cross-check with the till: filter by source to see how often your POS is hiding items you thought were on sale.

What This Does Not Do

It cannot tell you when an item came back, because there is no “back in stock” event. Read the log as “went out at”, not “was out for”.
It does not change availability. Un-snoozing and restocking happen in the dashboard or your till as before.
Events start from the moment you connect the endpoint. There is no history before that; the 30-day table fills up over the first month.
It is your service. storekit support can confirm an item.out_of_stock event reached your URL and the response code; the log and digest are yours.

item.out_of_stock payload

Every reason and source value the event can carry.

Writing a Prompt That Works

The structure behind this prompt, and what to say when the builder gets it wrong.

Order Alerts to Slack or Your Phone

The same pattern for orders instead of stock.

Availability and Snoozing

Snoozing, inventory and the built-in snooze report.

​How It Works

​What You Need

​Step 1: Build the App

​Step 2: Connect storekit

​Step 3: Test With a Real Stock-Out

​Ideas

​What This Does Not Do

​Related

item.out_of_stock payload

Writing a Prompt That Works

Order Alerts to Slack or Your Phone

Availability and Snoozing

How It Works

What You Need

Step 1: Build the App

Step 2: Connect storekit

Step 3: Test With a Real Stock-Out

Ideas

What This Does Not Do

Related