Widget embed.

This is a separate system from the Headless CMS API: the widget renders a complete, pre-built UI inside the host page. Use this when a tenant already has a website and just wants a menu/booking panel on it; use Headless CMS when a tenant is building their own frontend from scratch and wants raw data instead of a pre-built UI.

Installation

Paste this snippet where the widget should appear. It builds an isolated Shadow DOM host (so the tenant's page styles never leak in or out) and loads the widget bundle asynchronously.

<script async
  src="https://your-app-domain.com/widget/loader.js"
  data-key="pk_live_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX">
</script>

Theming

There are two ways brand colors/corner-radius reach the widget, and only one of them is what a real tenant embed actually uses:

1. Dashboard-persisted (the real path). A tenant sets accent color and corner style in their dashboard's widget settings; this is saved to their account and served back automatically in the catalog API's store.brand field on every load. This is what an actual embed snippet relies on — the copyable snippet in the dashboard never includes data-primary/data-radius.

2. Script-tag override. The data-primary/data-radius attributes on the loader tag exist and do work, but in this codebase they're only used by the dashboard's own live-preview iframe (so a color-picker change reflects instantly, before the debounced save completes).

GET/api/public/v1/catalog

Store info, booking flags, and the full menu catalog. This is what the widget bundle itself calls on mount.

Auth: ?key= query param. Cache: public, s-maxage=60, stale-while-revalidate=300 · Rate limit: 120 requests/minute per key.

{
  "store": {
    "name": "Restzo Cafe",
    "tagline": "Authentic. Hygienic. Welcoming.",
    "themeId": "classic",
    "whatsappNumber": "918349215106",
    "acceptingOrders": true,
    "gstPercent": 5,
    "brand": { "primary": "#c0392b", "radius": "12px" }
  },
  "booking": { "enabled": true, "advanceDays": 14, "maxPartySize": 20 },
  "categories": [
    {
      "id": "uuid",
      "name": "Paneer Specials",
      "nameLocal": "पनीर स्पेशल",
      "items": [
        {
          "id": "uuid",
          "name": "Kaju Curry",
          "nameLocal": "काजू करी",
          "price": 240,
          "priceHalf": 130,
          "description": null,
          "imageUrl": null,
          "foodType": "VEG",
          "isPopular": false
        }
      ]
    }
  ]
}

403 { "error": "Plan does not include the headless widget" } if the tenant's plan doesn't have the widget feature key enabled.

GET/api/public/v1/availability

Live per-slot seat availability for a given date — used by the widget's “Reserve” tab.

Query params: key, date (YYYY-MM-DD). Cache: no-store — capacity is live and must never be served stale. Rate limit: 120 requests/minute per key.

{
  "date": "2026-07-10",
  "slots": [
    { "time": "19:00", "available": 8 },
    { "time": "19:30", "available": 0 }
  ]
}

Slots are generated from the tenant's booking configuration (open/close time, slot length, lead time, advance-booking window) and computed in fixed IST (UTC+5:30). Past slots and slots inside the lead-time window are excluded entirely, not returned with available: 0.

400: { "error": "Missing key or date" } or { "error": "Invalid date" }. 404: { "error": "Reservations are not enabled" } if the tenant has booking turned off.

POST/api/public/v1/bookings

Creates a table reservation. Rate limited much tighter than the read endpoints since this is a write.

Rate limit: 15 requests/minute per key.

{
  "key": "pk_live_…",
  "date": "2026-07-10",
  "time": "19:00",
  "partySize": 4,
  "customerName": "Test Traveler",
  "customerPhone": "+917508839991",
  "notes": "Window seat if possible"
}

{
  "id": "uuid",
  "status": "CONFIRMED",
  "date": "2026-07-10",
  "time": "19:00",
  "partySize": 4,
  "businessName": "Restzo Cafe"
}

{ "error": "This slot just filled up", "remaining": 2 }

On success, a WhatsApp confirmation is queued to the customer's phone — this happens asynchronously and never blocks or alters the HTTP response, even if it fails.

Errors & rate limits

All three endpoints share the same auth model and CORS-open policy, but differ in a few real ways worth knowing before you build retry logic:

Plan gating is by feature key (widget for catalog, booking for availability/bookings) on whatever pricing plan a tenant is assigned — this is admin-configurable per plan, not a fixed hardcoded tier name, so don't hardcode “Gold/Platinum only” logic against the API itself.

Questions or something not covered here? Get in touch.