Remove a staff photo
/api/providers/{id}/avatarDeletes the stored object and nulls avatar_url.
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
Provider id.
Response Body
application/json
application/json
application/json
application/json
application/json
curl -X DELETE "https://example.com/api/providers/string/avatar"{ "ok": true}Upload a staff photo POST
Byte-for-byte the service-image route with the nouns swapped: bucket `staff-photos`, path `{companyId}/{providerId}`, same verify-then-upload ordering (the id is validated and the row confirmed to be the caller's before anything is written).
Request a date-specific schedule override POST
Submit a one-date replacement for this provider's recurring hours (migration 0052); more hours, fewer, or none at all (a day off). The approve-immediately-or-queue decision is made INSIDE `book_submit_availability_override`, from the caller's role, the provider's `availability_delegation` tier, and the org's `availability_approval_horizon_days`, all read from the database inside the function's own transaction, never trusted from this request body, so calling the underlying RPC directly cannot produce a different outcome than this route does. **Ownership**: an admin may submit for any provider in the org; any other role only for the provider row linked to their own login. An unlinked staff login gets 403; a deliberate fail-closed departure from this codebase's usual fail-open convention for an unlinked staff member, because that convention protects a front-desk person's own usability, not license to edit someone else's schedule with no approval. **Conflicts** against existing, non-cancelled appointments on the date are checked live, unconditionally. A staff caller with a conflict is always hard-blocked (409, nothing persisted); they already have the tool to fix it themselves (reschedule/cancel their own booking). An admin caller may proceed by sending `conflictAcknowledged: true`. On success, notifies the org's admins always, and the affected staff login too when the change applied without needing their own approval and they were not the one who submitted it (an admin acting on their behalf).