Render a live email preview of a draft campaign
/api/marketing/campaigns/{id}/previewA server round trip, DELIBERATELY not a zero-round-trip client-side render the way TemplateStudio.tsx's own preview works: {{booking_url}} resolves through appBaseUrl() (booking/manage.ts), which reads a server-only environment variable Next.js never inlines into a client bundle. Draft fields are read from the REQUEST BODY, never the saved row, since the point is previewing what the operator has typed but not yet autosaved. Renders against a fixed sample customer name, the same "real renderer against a sample" approach TemplateStudio.tsx uses for its own booking preview.
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
Campaign id (unused by the handler; the rendered company comes from the caller's own session).
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 POST "https://example.com/api/marketing/campaigns/string/preview" \ -H "Content-Type: application/json" \ -d '{}'{ "subject": "string", "html": "string"}Live "will reach N" count for a segment or tag GET
The compose screen's live audience preview, debounced against IN-MEMORY form state rather than the saved draft: it has to answer before autosave persists. `{id}` is not read; kept only for URL consistency with the rest of this feature's nested routes, since the count depends purely on company + kind + value. The emailable/consent filter (applyMarketingAudienceFilter, migration 0143) is always applied on top, same as the clients page's own `emailable` chip.
Send a campaign for real (admin, or manage_org_settings) POST
Re-checks every client-side checklist item server-side: never trust the client gate alone. Order matters: (1) validate and compute the audience READ-ONLY, (2) flip draft -> sending ATOMICALLY (`.eq('status','draft')` is what makes a double-click or a retry produce a 409 instead of a second materialization), (3) materialize book_campaign_recipients in 200-row chunks, (4) enqueue the first `campaign_chunk` job. If step 4's enqueue fails the response is still 200 with a `warning` field; the campaigns list route's own read self-heals a stuck send by re-enqueueing, the same "swept when somebody reads the job list" idiom flagStalledJobs already establishes for data jobs.