Remove an experience image
/api/experiences/{id}/imageDeletes the stored object and nulls image_url. Storage removal is best-effort and its failure does not fail the request.
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
Experience id.
Response Body
application/json
application/json
application/json
application/json
application/json
curl -X DELETE "https://example.com/api/experiences/string/image"{ "ok": true}Upload an experience image POST
Stores the file at `{companyId}/{experienceId}` in the `experience-images` bucket and writes a cache-busted public URL onto the experience row. Not gated on `manage_services`: a photo is part of editing the experience, same posture as the equivalent product-image route. Ownership is checked BEFORE the upload, so a request naming an experience the caller does not own is a 404 with nothing written.
The door-staff guestlist for one experience GET
Every ticket sold for this experience, who it's for, and whether it has been admitted. No `manage_services` gate, unlike the catalog routes above: checking a guest in is an ordinary front-of-house task every role needs at the door. A cancelled booking's ticket stays in the list (a cancelled guest should not simply vanish from what staff see) but never counts toward `admitted`/`total`.