Confirm a pencilled-in big-group booking
/api/enquiries/{id}/confirmThe 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.
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.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/api/enquiries/string/confirm"{ "ok": true, "reservationId": "54c41ef9-5629-4a9c-bb0d-10f615966bd0"}Release a pencilled-in hold DELETE
Deletes the reservation this enquiry was pencilled in on and hands the enquiry back as one with no live booking, ready to be pencilled in somewhere else. The group went elsewhere, or the date moved. **Delete, not cancel, and that is the point of it existing.** Cancelling enqueues `reservation_cancelled`, which emails the guest that their booking is off, for a hold they were never told about. Deleting frees the tables silently, cascades `book_reservation_tables` (0035), and lets 0039's `on delete set null (reservation_id)` clear the link. Refuses anything a guest has been told about or has paid for: only a `pending` or already-`cancelled` reservation with no payment intent. A confirmed booking is cancelled from the Reservations screen, where the guest is notified and the deposit is resolved.
Move a big-group enquiry along PATCH
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.