GuidesAPI ReferenceMCPChangelog
Hospitality engine

Hospitality's "Your booking funnel" (self-hosted, cookieless)

get/api/organization/reservations/funnel

The hospitality twin of getWebsiteAnalytics above, scoped to the one panel that's actually about the booking widget rather than a marketing site: no popular pages, referrers, devices or domain/publish status, since hospitality has no site pages for any of that to describe yet (see organization/website/page.tsx's own redirect). Same Umami plumbing (ensureUmamiWebsiteId, getUmamiEventCounts) and the same buildBookingFunnelSteps ranking/drop-off maths as the appointments funnel, over hospitality's own step vocabulary (RESERVATION_FUNNEL_STEP_ORDER, funnel-events.ts). The terminal "Booked" row is the reservation_completed Umami event count, not a DB ground-truth count the way appointments' via_website column gives it, since hospitality has no site to distinguish "arrived via the site" from "direct" (there is nothing that column would be truthful about). Surfaced on /reports, the one screen both verticals already share, not a hospitality-only "Website" nav item that does not exist.

Authorization

sessionCookie
sb-qxrvgfkjyvbngipqvslu-auth-token<token>

The dashboard's Supabase Auth session cookie, set at sign-in. Large sessions are split across numbered chunks (…auth-token.0, .1), so treat this as a cookie family rather than one name.

Every request re-validates it against the Auth server (getUser()), never by decoding the cookie locally: a JWT nothing has checked is not a credential. Tenancy is then read from the verified app_metadata.company_id claim and enforced by row-level security; it is never read from request input, on any route, ever.

role (admin / staff) is deliberately not in RLS. It gates specific actions in route code, the operations marked admin below, so hiding a button in the UI is cosmetic only, and a route's own check is the enforcement.

In: cookie

Query Parameters

days?integer

The trailing window. Anything else silently falls back to 30, same as getWebsiteAnalytics' identical parameter.

Value in

  • 7
  • 30
  • 90

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

curl -X GET "https://example.com/api/organization/reservations/funnel"
{  "days": 0,  "bookingFunnel": [    {      "key": "string",      "label": "string",      "visitors": 0,      "dropoffPct": 0    }  ]}

Scan or manually check in a ticket POST

One action, two callers: a live QR scan on /scanner sends `token` (extracted from the decoded ticket URL); the guestlist's own manual "Check in"/"Undo" button sends `ticketId` directly. Exactly one of the two is required. A cancelled or never-confirmed booking's ticket is refused outright. Scanning an already-admitted ticket is not an error: the response reports `alreadyCheckedIn: true` rather than re-admitting or refusing, which is the single most useful thing for the door to know (a duplicate ticket, a guest who stepped back out). `undo: true` clears a check-in instead (a mis-scan correction).

List bookable appointment slots GET

The public availability grid. Reads through the service-role client inside this route rather than through an anon RLS policy, so there is one security model to reason about rather than two. Slot allocation is first-come: for a given start time the first provider found free wins it. There is no fairness or least-booked balancing. Slots whose start time has already passed are filtered out, because the booking POST rejects them anyway. **Ranged mode (`days`).** Answers up to 14 consecutive days from `date` in one request, for the wizard's landing walk, which used to fire one request per day (up to 14) hunting for the first open one. The single-date shape (`{slots}`) is unchanged and stays the default; sending `days` greater than 1 switches the response to `{days: {"<date>": {slots}, ...}}`, one entry per requested date.