GuidesAPI ReferenceMCPChangelog
Hospitality engine

Remove an adjacency edge

delete/api/link-adjacencies/{id}

Deletes one book_table_link_adjacencies row. Both tables and their group are untouched: this only withdraws staff's claim that the two tables sit next to each other, the same way removing a furniture-set combo withdraws a combining permission without touching the pieces it named.

Authorization

sessionCookie
sb-qxrvgfkjyvbngipqvslu-auth-token<token>

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

id*string

Adjacency edge id.

Response Body

application/json

application/json

application/json

application/json

application/json

curl -X DELETE "https://example.com/api/link-adjacencies/string"
{  "ok": true}

Draw an adjacency edge between two tables POST

Both tables must already belong to the SAME book_table_link_groups row (an ordinary combine group, never a furniture-set piece, which has its own separate combo mechanism); validated server-side, not just by the parser. No Venue Pro gate: an edge only refines an already-created group's own combining behaviour, it cannot create a new combinable group. Idempotent on a duplicate (`alreadyExists: true`), since the canvas' click-to-connect toggle already checks its own edge list before calling this: a repeat only fires on a genuine race between two staff drawing the same line at once.

Area locks touching a date GET

Every lock overlapping one UTC calendar day, whatever tier it names. A lock running 22:00 into tomorrow's 02:00 is returned for **both** days; a host looking at either one needs to see it. The overlap test is the same half-open comparison the allocator applies to instants and the public booking routes apply in SQL, so this screen and the booking page can never disagree about whether a lock covers a day.