Cancel or reject an availability-override request
/api/availability-overrides/{id}Two plain status transitions on a pending row: cancelled (the staff member who owns the linked provider, on their own row, or any admin) and rejected (admin only). approved is deliberately refused here even though the request shape alone would not stop it; it is a special action (POST .../approve), same rule PATCH /api/waitlist/{id} enforces for notified. superseded is never client-settable at all.
Both transitions call a SECURITY INVOKER database function (book_cancel_availability_override / book_decide_availability_override, migration 0052) rather than writing the row directly; this table has no update policy for authenticated at all, so a raw PostgREST update would be refused the same way from anywhere else. The functions re-check role/ownership themselves from the database; this route's own gates are the ordinary UX path, not the enforcement.
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
Availability-override request id.
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
curl -X PATCH "https://example.com/api/availability-overrides/string" \ -H "Content-Type: application/json" \ -d '{ "status": "cancelled" }'{ "ok": true}List availability-override requests GET
Staff sees only their own linked provider's rows (server-forced, ignoring any client filter; there is none to send); admin sees every row across every status, so this one endpoint powers both a "needs attention" view (filter client-side on `status: pending`, or `approved` with `conflictAcknowledged` and `conflictCount > 0`) and a full history view. `conflictCount` is recomputed live on every call for an admin caller (always 0 for staff); migration 0052 deliberately does not persist which appointments conflicted, so a later cancellation or reassignment through the ordinary calendar screen makes a row stop needing attention with no write required.
Approve a pending availability-override request POST
Admin only, mirroring POST /api/waitlist/{id}/offer's shape (a special action gets its own route rather than being a plain status PATCH). Re-runs the conflict check LIVE rather than trusting anything the client sends; a booking made after the request was submitted, or after the admin last looked at the list, must not be silently approved over. **Reassignment is not a parameter here.** The dashboard calls the existing, unmodified PATCH /api/appointments/{id} for each conflicting booking it wants to move, sequentially, BEFORE calling this route, never one endpoint doing both, so a failed reassignment cannot leave the override half-decided. Notifies the submitting staff member's linked login on success.