Enable or disable a promotion (admin, or manage_org_settings)
/api/marketing/promotions/{id}The one lifecycle action this v1 dashboard exposes: no delete, no field edits after creation. Revalidates the public booking page cache the same way POST does, so a disabled sale stops showing immediately rather than lagging the 5-minute window.
Authorization
sessionCookie 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
Path Parameters
Promotion id.
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
curl -X PATCH "https://example.com/api/marketing/promotions/string" \ -H "Content-Type: application/json" \ -d '{ "status": "active" }'{ "ok": true, "status": "active"}Create a promotion: an automatic sale or a promo code (admin, or manage_org_settings) POST
One route for both kinds (migration 0163): an automatic "sale" discounts the public appointments booking page with no code, a "code" is typed by the guest at checkout. Appointments only: reservations (hospitality) carry no priced total to discount. A "code" with no explicit `code` field generates one from `name` (src/lib/marketing/promotions/codes.ts), retrying up to 3 times on the rare per-company collision; an EXPLICIT code that collides is refused (409) rather than silently regenerated, since that collision is the venue's own typo to fix. Revalidates the public booking page cache (bookingConfigTag) on a 'sale' so the struck-through price appears without waiting the full 5-minute window.
Save the Booking Page settings draft (admin, or manage_org_settings) PATCH
Writes `draft_content` ONLY (`book_booking_page_drafts`, migration 20260911151213); `book_companies`' own accent_color/tagline/booking_theme/etc. columns, which the public widget, emails, wallet passes and marketing campaigns all read as the live published truth, never move until POST .../publish. Same admin-or-manage_org_settings gate as PATCH /api/companies, since this is the exact same bucket of settings, just landing in a different column for now. Accepts a PARTIAL patch: only the keys present in the body are validated and merged onto whatever draft already exists (BOOKING_PAGE_DRAFT_FIELDS, src/lib/booking/booking-page-draft-input.ts). An unknown key, or any field failing its own validation, rejects the whole patch with a 400 naming the first problem found. Both verticals: the Booking Page settings screen applies to every company regardless of business_type, so this route names no engine.