Update a product, or archive/restore it
/api/products/{id}Two shapes in one route. A body of exactly {"archived": true|false} sets/clears archived_at and returns immediately, no other field required. Any other body is a full replacement of the catalog fields (parseProductInput's contract); stockOnHand is never accepted here, only through POST /api/products/{id}/stock. RLS scopes the update, so an id from another org matches zero rows and returns 404. Appointments only, see POST /api/products.
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
Product 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
curl -X PATCH "https://example.com/api/products/string" \ -H "Content-Type: application/json" \ -d '{ "archived": true }'{ "ok": true}Create a product POST
Adds a retail catalog item. `company_id` comes from the verified JWT claim, never the body. `stockOnHand` is the opening count, written directly ONLY on create: every change after this goes through POST /api/products/{id}/stock, which records a reason. **Appointments only** as of 2026-09-06: see migration 0200's own comment for why hospitality never had a real equivalent here at all, and /api/experiences for the screen it actually gets.
Upload a product image POST
Stores the file at `{companyId}/{productId}` in the `product-images` bucket and writes a cache-busted public URL onto the product row. Not gated on `manage_services`: a photo is part of editing the product, same posture as the equivalent service-image route. Ownership is checked BEFORE the upload, so a request naming a product the caller does not own is a 404 with nothing written. **Appointments only**, see POST /api/products.