Email via Resend (template)

How this differs from "Email — Resend"

The original Resend destination asks you to paste the subject and HTML body into LeadRails as templates. This one keeps the whole email in Resend instead. You design the template in Resend's editor, and LeadRails only supplies the recipient and the variables. Two upsides: the email lives where you can preview and version it, and LeadRails never holds your email markup.

What LeadRails sends

For each lead, LeadRails POSTs to Resend's /emails endpoint with this shape and nothing else:

{
  "to": "jane@example.com",
  "template": {
    "id": "tmpl_abc123",
    "variables": { "name": "Jane Smith", "message": "Need a quote" }
  }
}

The from, subject, and body all live on the Resend template. LeadRails does not send them. The to comes from your route's mapping. Every other mapped field becomes a variable your template can reference.

Config fields

API key (required)

Your Resend API key, starts with re_. Generate one at resend.com/api-keys. A "Sending access" key is enough to deliver. A "Full access" key additionally lets LeadRails read your template so the route editor can show you the template's variables.

Template ID (required)

The Resend template ID (looks like tmpl_xxx). The template owns the subject, from address, and body.

Get set up

1. In Resend, create the email as a template. Note its template ID.
2. Verify a sending domain in Resend under Domains (see below).
3. Create an API key at resend.com/api-keys.
4. In LeadRails: Destinations → New → adapter type Email — Resend (template).
5. Paste your API key and the template ID. Click Create.
6. On a route to this destination, map to to the lead's email. Map any other fields your template uses.

Verify a sending domain

Resend only sends from a verified domain. In Resend: Domains → Add Domain → add the SPF and DKIM DNS records it shows you, then click Verify. Until a domain is verified, Resend rejects sends with a 422.

How "Verify connection" behaves

Open the destination → Verify connection. LeadRails calls Resend's /domains endpoint with your key. It never sends a lead.

• Key works and a domain is verified: you get a pass.
• Key works but no domain is verified yet: you get a failure that says so, up front. That's on purpose. It's the same thing that would otherwise fail your first real send with a 422.
• Sending-only key: LeadRails confirms the key works and reminds you to check the domain yourself. A sending-only key can't read your domains, so LeadRails can't check that part for you.
• Key rejected: check the value and try again.

Failure modes

401 / 403

API key wrong, revoked, or too narrow. LeadRails alerts on this and stops retrying.

404

The template ID doesn't exist under this key. Fix the template ID on the destination.

422 + "validation_error"

Resend refused the send. Most often the sending domain isn't verified, or the template is missing a required variable. LeadRails flags this as a destination_config_failed alert and stops retrying, because a retry would fail the same way.

429

You hit Resend's rate limit. LeadRails backs off and retries, honoring Resend's Retry-After.

500 and up, timeouts, network errors

Treated as temporary. LeadRails retries up to 5 times with backoff, then alerts if it still won't go through.

Available variables

Whatever you map on the route (besides to) is passed to the template as a variable of the same name. Your template decides which it uses. If your key has Full access, the route editor shows the template's declared variables so you can map them by name.

Your responsibilities

• You are the sender. Anti-spam laws (CAN-SPAM US, CASL Canada, GDPR EU) are yours.
• Lead-routing emails are usually transactional, which carries a lower compliance bar than marketing email.
• Wire Resend's Bounce and Complaint webhooks to your own backend to handle suppressions.