resend-ops

name	resend-ops
description	Plan, implement, verify, and operate Resend lifecycle email for web apps. Use when Codex needs to handle Resend API keys, verified sending domains, DNS records, SDK setup, transactional email sending, templates, lifecycle email plans, webhooks, unsubscribe/compliance notes, testing, logging, or human Resend Dashboard setup tasks.

Resend Ops

Freshness

These instructions are based on official Resend documentation reviewed on 2026-06-24. The fetched Resend docs did not expose a stable docs version or last-updated timestamp in the page content, so treat this as a review-date stamp. Re-check official Resend docs before changing production domain, DNS, API key, webhook, deliverability, or compliance behavior.

Goal

Make lifecycle email deliberate and reliable: verified domains, scoped API keys, server-only sending, clear templates, explicit triggers, unsubscribe/compliance handling, local/test verification, and human DNS/account tasks separated from code work.

Default Approach

Assume a React/Vite/Firebase app unless the repo shows otherwise.

• Use Resend from trusted server code, such as Firebase Cloud Functions.
• Keep RESEND_API_KEY server-only.
• Send from a verified domain or subdomain.
• Prefer a purpose-specific sending subdomain, such as updates.example.com, for reputation isolation.
• Plan lifecycle emails as product events with owner, trigger, audience, template variables, and failure behavior.
• Use Resend webhooks when delivery, bounce, complaint, open, or click feedback is needed.
• Document all DNS, domain, key, and webhook setup tasks.

Workflow

1. Inspect the repo. Identify backend boundary, existing email code, env handling, templates, user data, consent model, and docs.

2. Classify the task. Read references/task-routing.md to choose setup, sending, templates, webhooks, compliance, or testing.

3. Separate human setup from code work. Human tasks include creating a Resend account/team, adding a domain, updating DNS, verifying the domain, creating API keys, configuring webhooks, and approving compliance copy.

4. Design the lifecycle plan. Keep V1 emails few and useful. Each email needs a trigger, audience, purpose, subject, sender, template variables, suppression rule, and test case.

5. Put sending on the server. Do not send directly from browser code. Keep API keys in server secret storage or CI/hosting secret stores.

6. Verify deliverability and failure paths. Test successful sends, invalid recipient behavior, missing template data, bounced/complained events if webhooks are in scope, and logging.

7. Document operations. Update docs/resend.md and docs/env.md with setup, DNS, local testing, templates, events, webhooks, and support notes.

Reference Files

• Read references/task-routing.md to choose the Resend workflow.
• Read references/domain-and-keys.md before planning domains, DNS, API keys, sender addresses, or secrets.
• Read references/lifecycle-emails.md before planning or implementing email events/templates.
• Read references/webhooks-testing-compliance.md before implementing webhooks, unsubscribe handling, testing, or deliverability/compliance notes.

Operating Rules

• Never commit Resend API keys or production .env files.
• Never expose Resend API keys in Vite VITE_* env vars or browser bundles.
• Do not email real users from local/test code unless the user explicitly asks and the audience is approved.
• Avoid logging full email bodies, secrets, or unnecessary personal data.
• Do not invent legal compliance; call out human review for marketing consent, unsubscribe rules, privacy policy, and regulated content.
• Prefer one focused sender module and one template file/component per email.
• Keep transactional and marketing/broadcast assumptions separate.

Outputs

For planning tasks, produce:

• Email lifecycle map.
• Human Resend setup checklist.
• Domain/DNS/API key plan.
• Template inventory.
• Required env vars and secrets.
• Webhook and event plan.
• Testing and compliance checklist.

For implementation tasks, produce:

• Server-side Resend integration changes.
• Template changes.
• Updated docs.
• Verification results.
• Remaining human Dashboard/DNS tasks.