Assign a table to a server for a date
/api/server-assignmentsThe whole assignment API in one verb: a serverId gives the table to that server for the date (upsert on the one-server-per-table-per-date key), an explicit null takes it back. Per-DATE, not per-service: sections are chalked up once for the night.
No same-tenant checks in the route. Both foreign keys are composite over company_id (0011's pattern), so a cross-tenant table or server id is rejected by the database itself.
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
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
curl -X PUT "https://example.com/api/server-assignments" \ -H "Content-Type: application/json" \ -d '{ "date": "string", "tableId": "073fbfcb-cd05-4203-be18-a1ce6f8e4d2d", "serverId": "10d2345a-e43d-463d-830e-4f5b19b60d41" }'{ "ok": true}Remove a floor server DELETE
Hard delete: the row is a label, and its table assignments cascade away with it (0097). Use the PATCH above to rename rather than delete-and-re-add, precisely because of that cascade.
Update a reservation PATCH
The reservations twin of PATCH /api/appointments/{id}: partial, only present keys are written. Deliberately NOT re-checked on edit: the table's seat range and the period's cover cap. A host seating five on a four-top is a real thing venues do and the reason a manual override screen exists. The double-booking constraint is the one rule staff cannot override, and Postgres enforces it.