Move a big-group enquiry along
/api/enquiries/{id}Sets status to new, open, won or lost. The ONLY field staff can change: everything else on the row is what the guest sent, and an enquiry is a record of what was asked for, not a form the venue edits.
No minRole; dealing with an enquiry is ordinary floor work, the same reasoning that lets any member reply to a booking message.
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
Enquiry 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
curl -X PATCH "https://example.com/api/enquiries/string" \ -H "Content-Type: application/json" \ -d '{ "status": "new" }'{ "ok": true}Confirm a pencilled-in big-group booking POST
The second half of the two-stage conversion: the hold becomes a booking the venue has actually promised. Flips the reservation from `pending` to `confirmed` (the trigger in 0035 carries every companion table with it), sets the enquiry to `won`, and posts the "Booked" line into the thread. Three writes that must agree, which is why this is one route and not three fetches from the browser. A client could PATCH the reservation and then PATCH the enquiry; what it could not do is guarantee the second happens, and the failure that leaves behind is a confirmed booking whose conversation never mentions it, the exact thing this feature exists to prevent. Compare-and-set on `where status = 'pending'`, so two hosts hitting Confirm at once produce one confirmation and one 409, not two "Booked" lines. **No notification is sent, deliberately**, matching the one-shot conversion. Confirming a big group ends a conversation the staff are already having in this thread; the reply they are about to type is the confirmation.
Create a link group POST
A named run of tables the venue can physically push together to seat a party too big for any single table (migration 0035). Tables join a group through `linkGroupId` on the table itself, so this endpoint only names the group. Two behaviours worth knowing before turning this on. **Grouped tables are allocated LAST**: when a small party fits either a grouped table or an ungrouped one of the same size, the ungrouped one wins, so the run stays whole for a big booking. And **a combination never crosses a group** and never exceeds 4 tables; the cap bounds a subset search reachable from the public availability endpoint.