Resend Visual Tech Stack

Recommended for server-controlled transactional email with delivery proof

This is a scoped recommendation for the use case shown, not a universal optimum or an installed integration.

Core architecture

| Layer | Component | Role | | --- | --- | --- | | Input | Validated event | Authorized request • idempotency key | | Input | Email content | Recipient • verified sender • template | | Input | Backend config | Private key • domain verification | | Core | Resend | Accept email requests • expose delivery events | | Quality gate | Delivery & inbox review | Provider ID • event status • receipt | | Output | Recipient inbox | Confirm actual test delivery | | Output | Message ledger | Keep IDs, attempts, and outcomes |

Connection labels

1. Send from a trusted backend with private credentials 2. Inspect message events and verify inbox receipt 3. Persist delivery outcomes and handle retries

Blue lines indicate manual/local workflow steps. Purple dashed lines indicate a separately configured connection, which may include human gates; they are not claims that the entire path is unattended. Orange indicates review/refinement. Core diagram mode: configured.

Supporting tools

• Server framework: Validate requests and authorize sends.
• Supabase / database: Optional durable outbox and status log.
• Job scheduler: Optional controlled queue dispatch.

What to check

• Secret placement: Keep sending credentials out of browsers.
• Sender setup: Use the correct verified sending domain.
• Delivery distinction: Accepted is not the same as inbox receipt.

Optional extension

• App event: Create a valid job
• Outbox database: Store send intent
• Server worker: Send with controls
• Resend API: Accept the message
• Event handler: Update the ledger

Optional durable email pipeline. Configure verified domains, server credentials, idempotency, event-webhook signature validation, and retry policy. Inbox checks remain separate from provider acceptance.

Lean starter

Trusted server code + Resend + a verified domain. Add a queue or database only when you need durable retries and tracking.

Example

Authorized booking event → one queued intent → controlled send → delivery event → confirm the test message arrives.

Series 40 / 40