Send a catalog form to a customer
/api/form-sendsSnapshots title/description/fields off the CURRENT book_forms row onto a new book_form_sends row, mints its token, and best-effort emails the customer a link (notifyFormSent): the row exists and the link is returned either way, so a failed send never loses the credential. Service-role, not the RLS-scoped client: book_form_sends has no INSERT grant for authenticated at all. Same permission bar as the catalog routes above (admin, intake_forms): sending an existing form is still deciding what a business asks a customer.
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
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 POST "https://example.com/api/form-sends" \ -H "Content-Type: application/json" \ -d '{ "customerId": "87d8e330-2878-4742-a86f-dbbb3bf522ac", "formId": "126460ed-49b2-4c69-849a-bd8904ec5d8f" }'{ "formSend": { "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "token": "b5507016-7da2-4777-a161-1e8042a6a377", "sentAt": "2019-08-24T14:15:22Z", "url": "string" }}Edit a catalog form, or toggle active (admin) PATCH
Same shape PATCH /api/packages/{id} takes: a body of exactly `{ active: boolean }` toggles that flag alone; anything else is validated and written as a full replace via parseFormInput. No DELETE: book_form_sends references form_id with ON DELETE SET NULL rather than CASCADE, so a form already sent keeps its own snapshot regardless, but deactivating rather than deleting keeps the catalog list honest about what is still offered.
A customer answers a sent form (public, unauthenticated) PUT
The guest side of the standalone Forms feature. The token is the entire credential, same posture the manage-token routes take (0018): every write is scoped to the company_id resolved FROM the token, never from the request body. Replace semantics: a customer reopening the link edits their answers rather than stacking a second submission. No GET: src/app/forms/[token]/page.tsx loads the send directly on the server with its own service-role read.