Resend environment (as-built) - PolicyCodex Support

Captured live from https://api.resend.com using the key in .env.local (RESEND_API_KEY) on 2026-08-13. Automations and templates ARE queryable and creatable via the Resend API (GET/POST /automations, GET/POST /templates, POST /templates/{id}/publish) — this page is proof, and Gap 4 below was closed the same way. Re-run the calls below to refresh; nothing here is hand-maintained. Resend has no staging environment — this is production, so POST /events/send sends a real email.

Design at a glance

Custom events (7)

Event names are namespaced codex: — Resend reserves the resend: prefix for its own system events. Only one carries a declared schema.

Event	Schema	Fired from	Payload sent
`codex:user_signed_up`	—	`clerk-to-resend` on Clerk `user.created`	`{ first_name }`
`codex:subscription_plan_changed`	`{ plan: string }`	`clerk-to-resend` on `subscriptionItem.*` reaching an entitled status, non-free plan	`{ plan, plan_name }`
`codex:subscription_cancelled`	—	`clerk-to-resend` on `subscriptionItem.*` reaching canceled/ended	`{ plan, plan_name }` — also unsubscribes the contact (`PATCH /contacts/:email`); see the automation below
`codex:github_integration_added`	—	`github-scan`, once per installation (`connected_notified_at` gate)	`{}`
`codex:first_full_scan`	—	`github-scan`, once per installation (`first_scan_notified_at` gate)	`{ first_name }`
`codex:first_violation_found`	—	worker (`db.ts`), once per org (row-count comparison, no extra column)	`{ severity }`
`codex:first_violation_resolved`	—	worker (`db.ts`), once per org	`{ severity }`

All product-milestone sends (everything except signup and billing) go to every domain_owner of the affected org, resolved via members → user_profiles. Every sender is best-effort: a missing RESEND_API_KEY or a Resend outage is swallowed (.catch() at the call site) and never fails the request that triggered it.

Automations (7)

Each automation triggers on event_received for exactly one event above.

Automation	Trigger event	Shape
New User Signup	`codex:user_signed_up`	linear, 7 sends over 22 days — see diagram below
Subscription Plan Changed	`codex:subscription_plan_changed`	3-way branch on `event.plan` — see diagram below
Subscription Cancelled ✨	`codex:subscription_cancelled`	trigger → send. Added 2026-08-13 to close the gap below
GitHub Integration Added	`codex:github_integration_added`	trigger → send
First Violation Found	`codex:first_violation_found`	trigger → send
First Violation Resolved	`codex:first_violation_resolved`	trigger → send
First Full Scan	`codex:first_full_scan`	trigger → send

All six free-signup-* templates are now wired in, end to end. Timing changed too — the gap before the second email dropped from the original 1 week to 1 day.

Day	Template	Notes
0	`free-signup-01-love-letter`	Sent immediately on trigger; followed by `add_to_segment` (General)
1	`free-signup-02-belief-breaker`	Sender `noreply@mailer.policycodex.cloud`; only step with explicit variable overrides (`APP_URL` → `www.policycodex.cloud`, `DASHBOARD_URL`)
4	`free-signup-02-belief-breaker`	Same template sent a second time — see the as-built note below
7	`free-signup-03-value-drop`
12	`free-signup-04-story-bridge`
17	`free-signup-05-proof`
22	`free-signup-06-squeeze`	Sequence ends here

As-built observation, not a defect flag: free-signup-02-belief-breaker is referenced by two separate send_email steps (day 1 and day 4) — every other template in the sequence is sent exactly once. This may be a deliberate second touch on the same asset, or an artifact of assembling the sequence in the Resend dashboard. Worth a glance next time the sequence is edited, not urgent.

Subscription Plan Changed — the only branching automation

Three static templates, one per plan — not one dynamic template driven by a PLAN_NAME variable, even though the code computes plan_name for the payload. See Gap 3.

Subscription Cancelled — added 2026-08-13

Deliberately plan-agnostic copy — it does not reference event.plan_name. Given Gap 2’s unresolved question about whether Resend auto-binds event-payload keys to template variables, this automation was built to not depend on the answer either way.

Templates (14)

All published, dark-themed (#070c1c ink / #02c39a teal — the product’s own brand tokens), sender PolicyCodex <info@mailer.policycodex.cloud>.

Template alias	Subject	Variables (fallback)	Used by
`free-signup-01-love-letter`	You’re in — here’s your first codex	`RECIPIENT_FIRST_NAME` (there), `APP_URL`, `DASHBOARD_URL`	New User Signup, day 0
`free-signup-02-belief-breaker`	Your standards doc is not a standard	`APP_URL`, `DASHBOARD_URL`	New User Signup, day 1 and day 4
`free-signup-03-value-drop`	The 3-line trick that makes AI agents follow your standards	`DOCS_URL`, `APP_URL`	New User Signup, day 7
`free-signup-04-story-bridge`	”We found out three weeks before the audit, not during it”	`APP_URL`, `DASHBOARD_URL`	New User Signup, day 12
`free-signup-05-proof`	What “enforced” actually looks like after 30 days	`APP_URL`, `DASHBOARD_URL`	New User Signup, day 17
`free-signup-06-squeeze`	Your Free plan caps at 10 engineers	`APP_URL`, `PRICING_URL`	New User Signup, day 22 (sequence end)
`event-github-integration-added`	GitHub is connected	`DASHBOARD_URL`, `APP_URL`	GitHub Integration Added
`event-first-violation-found`	Your first violation just got caught	`DASHBOARD_URL`, `APP_URL`	First Violation Found
`event-first-violation-resolved`	Your first violation is resolved	`DASHBOARD_URL`, `APP_URL`	First Violation Resolved
`event-first-full-scan`	Your first full scan is done	`RECIPIENT_FIRST_NAME` (there), `DASHBOARD_URL`, `APP_URL`	First Full Scan
`event-subscription-plan-changed-team`	You’re now on Team	`APP_URL`, `DASHBOARD_URL`	Subscription Plan Changed, `plan == team`
`event-subscription-plan-changed-growth`	You’re now on Growth	`APP_URL`, `DASHBOARD_URL`	Subscription Plan Changed, `plan == growth`
`event-subscription-plan-changed-compliance`	You’re now on Compliance	`APP_URL`, `DASHBOARD_URL`	Subscription Plan Changed, `plan == compliance`
`event-subscription-cancelled` ✨	Sorry to see you go	`APP_URL`, `CONTACT_URL` (both with safe fallbacks)	Subscription Cancelled

Segments / Audiences (1)

“General” (6decbfb4-997b-45b3-b984-cc89246f0db5). Resend exposes the same contact list under two API paths — GET /audiences/{id}/contacts and GET /segments/{id}/contacts return identical data; this is one resource with a naming transition in Resend’s own API, not two lists to keep in sync. Membership is added only by the New User Signup automation’s add_to_segment step; nothing in this codebase removes a contact from it (cancellation only sets unsubscribed: true via the Contacts API, which stops sends without leaving the segment).

Webhooks (1)

Endpoint	Events subscribed
`resend-webhook` (`…supabase.co/functions/v1/resend-webhook`)	`email.sent`, `delivered`, `delivery_delayed`, `bounced`, `complained`, `opened`, `clicked`, `received`, `scheduled`, `suppressed`, `failed` — the full event set

Signed with Svix, verified against RESEND_WEBHOOK_SIGNING_SECRET (distinct from Clerk’s signing secrets). See Growth data flows for how events become email_sends/email_events rows.

API keys (4, Resend’s own — not this repo’s secrets)

Name	Purpose (by usage)
Supabase Integration	The value stored as the `RESEND_API_KEY` function secret — used by `clerk-to-resend`, `resend-webhook`, and `github-scan`’s milestone emails
GrowthApplication	Named for the growth workstream; not called directly by `apps/growth` (that SPA never touches Resend — see Growth overview)
cal-policycodex	Scoped to the Cal.com-adjacent workflow
Onboarding	Never used (`last_used_at: null`)

Findings for engineering

These are observations from the live account, not confirmed bugs — flagged here so engineering can decide, not fixed by this documentation pass.

Gap 1: `RECIPIENT_FIRST_NAME` is very likely never populated

Two call sites send a lowercase snake_case payload key, first_name: clerk-to-resend’s handleUserCreated and github-scan’s notifyGithubMilestones (first-scan branch). The templates that want a first name declare the variable as RECIPIENT_FIRST_NAME (free-signup-01-love-letter, event-first-full-scan). Neither automation step maps event.first_name → RECIPIENT_FIRST_NAME explicitly (the one place this codebase does map variables explicitly is New User Signup’s second send_email step, for APP_URL/DASHBOARD_URL). Unless Resend does case/format- insensitive auto-binding from event payload keys to variable names, every send of these two templates falls back to the literal string “there” — never a name. Confirm behaviour with a live probe (see below) before treating this as certain.

Gap 2: `plan_name` payload field is unused

clerk-to-resend computes a display name (planDisplayName(planSlug)) and sends it as plan_name in the codex:subscription_plan_changed payload. But the automation branches into three static templates (one hardcoded name per plan in the HTML itself), none of which declares a PLAN_NAME variable. The computed value is currently dead code from Resend’s perspective — either the templates were meant to merge, or the branch-to-static-template design superseded it and plan_name can be dropped from the payload.

Operational note: demo provisioning writes into the live segment

pnpm demo:provision creates real Clerk users for the ACME demo estate (owner+clerk_test@acme.example.com etc.), which fire real user.created webhooks, which flow through this exact pipeline into the live “General” segment — confirmed live: all three ACME demo addresses are in it today. Harmless (synthetic addresses, Clerk test-mode) but worth knowing before reading segment size as a real-lead count.

Reproducing this audit

RK="$(grep -E '^RESEND_API_KEY=' .env.local | cut -d= -f2)"

# inventory
curl -s https://api.resend.com/automations -H "Authorization: Bearer $RK" | python3 -m json.tool
curl -s https://api.resend.com/templates    -H "Authorization: Bearer $RK" | python3 -m json.tool
curl -s https://api.resend.com/events       -H "Authorization: Bearer $RK" | python3 -m json.tool
curl -s https://api.resend.com/segments     -H "Authorization: Bearer $RK" | python3 -m json.tool
curl -s https://api.resend.com/webhooks     -H "Authorization: Bearer $RK" | python3 -m json.tool

# one automation's full step/connection graph
curl -s https://api.resend.com/automations/<id> -H "Authorization: Bearer $RK" | python3 -m json.tool

# probe Gap 2 directly: does a lowercase payload key bind to an uppercase variable?
curl -s -X POST https://api.resend.com/events/send \
  -H "Authorization: Bearer $RK" -H "content-type: application/json" \
  -d '{"event":"codex:first_full_scan","email":"you@example.com","payload":{"first_name":"Ava"}}'
# then check the received email: does it greet "Ava" or fall back to "there"?

GET /automations and GET /templates are read-only inventory calls, safe to run any time. POST /events/send sends a real email to the address given — only use your own inbox, never a customer’s.

​Design at a glance

​Custom events (7)

​Automations (7)

​New User Signup — the full free-tier drip (completed 2026-08-13)

​Subscription Plan Changed — the only branching automation

​Subscription Cancelled — added 2026-08-13

​Templates (14)

​Segments / Audiences (1)

​Webhooks (1)

​API keys (4, Resend’s own — not this repo’s secrets)

​Findings for engineering

​Gap 1: RECIPIENT_FIRST_NAME is very likely never populated

​Gap 2: plan_name payload field is unused

​Operational note: demo provisioning writes into the live segment

​Reproducing this audit

Design at a glance

Custom events (7)

Automations (7)

New User Signup — the full free-tier drip (completed 2026-08-13)

Subscription Plan Changed — the only branching automation

Subscription Cancelled — added 2026-08-13

Templates (14)

Segments / Audiences (1)

Webhooks (1)

API keys (4, Resend’s own — not this repo’s secrets)

Findings for engineering

Gap 1: `RECIPIENT_FIRST_NAME` is very likely never populated

Gap 2: `plan_name` payload field is unused

Operational note: demo provisioning writes into the live segment

Reproducing this audit