Release a held table
/api/book/{slug}/reservations/{id}The guest closed the sheet or hit back. Releases the table immediately rather than waiting out the hold window. Only ever deletes a row whose status is still hold; a confirmed booking is cancelled from the dashboard or the manage link, never dropped by an unauthenticated caller holding an id.
Path Parameters
The organization's public booking slug, i.e. the {slug} in /{slug}. Only orgs with status active resolve; anything else is a 404.
The reservation id from the hold.
Response Body
application/json
application/json
curl -X DELETE "https://example.com/api/book/string/reservations/string"{ "released": true}Confirm a held table (guest checkout, step 2) PATCH
Attaches the guest's details and promotes the hold to `confirmed`. The update is a compare-and-set on `status = hold`, so two racing confirms cannot both succeed; the loser gets 410 and, importantly, does not send a "table confirmed" email for a booking it did not make. `hold_expires_at` is cleared in the same statement because the check constraint is biconditional; setting status alone would fail.
Message the venue about a booking POST
Allowed regardless of the change cutoff and on any status, unlike PATCH and DELETE. "I am running late" and "why was this cancelled" are exactly the moments someone needs to reach a venue; refusing them because the booking is two hours away would be backwards. A manage link is public to anyone holding it, so there is a flood cap: 20 guest messages per booking, after which the guest is told to contact the venue directly. That is a cheap guard, not real rate limiting; there is none anywhere in this API yet.