Remove a floor server
/api/servers/{id}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.
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
Server id.
Response Body
application/json
application/json
application/json
application/json
application/json
curl -X DELETE "https://example.com/api/servers/string"{ "ok": true}Rename a floor server PATCH
Name only. The section colour stays assigned by `POST /api/servers`, round-robin over a fixed palette: it exists to keep sections visually distinct on the map rather than to be chosen, and letting two servers land on the same hue would quietly break the thing it is for. This endpoint did not exist until 2026-08-10, on the reasoning that "rename is delete-and-re-add, and nothing else references a server by id". The second half was wrong: `book_server_assignments` references it, and those are exactly what the DELETE below cascades. So fixing a typo in a name wiped every table that server held for that date, mid-service. Renaming in place keeps the assignments.
Assign a table to a server for a date PUT
The 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.