Update a package, or activate/deactivate it
/api/packages/{id}Two shapes in one route, same posture PATCH /api/products/{id} takes. A body of exactly {"active": true|false} sets the flag and returns immediately. Any other body is a full replacement of the catalog fields (parsePackageInput's contract) followed by a delete-then-reinsert of book_package_services. RLS scopes the update, so an id from another org matches zero rows and returns 404. Appointments only, see POST /api/packages.
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
Package 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/packages/string" \ -H "Content-Type: application/json" \ -d '{ "active": true }'{ "ok": true}Create a package POST
Adds a catalog item: a set of prepaid visits covering one or more services. `company_id` comes from the verified JWT claim, never the body. Writes book_packages then book_package_services in two sequential statements (no RPC transaction); if the second write fails, the just-created package is deleted rather than left with no services on it. **Appointments only**, see migration 20260917130000's own header.
Sell a package to a customer POST
Snapshots name/price/sessions off the CURRENT book_packages row onto a new book_customer_packages row: v1's only sale path (BeNotely also sells from "New sale" and at close-out; both are follow-ups, see migration 20260917130000's own header). Service-role, not the RLS-scoped client: book_customer_packages has no INSERT grant for `authenticated` at all. No `manage_services` gate; selling an existing catalog item to a customer is the same everyday action a walk-in sale or a close-out payment already is.