Skip to content

Integration

Resend Integration

Transactional email with authenticated domains, typed templates, idempotent sending, and delivery events written back against the customer record.

Typical use cases
  • Quote and proposal delivery with a recorded sent state
  • Booking confirmations and reminders at defined offsets
  • Order confirmations, shipping notifications and receipts
  • Password reset and account verification
  • Internal notification when a form is submitted or a record needs attention

Overview

What this integration involves

Resend sends transactional email through an API. The integration work is small. The work that decides whether the email arrives is domain authentication, suppression handling and sending discipline.

Transactional mail has different requirements from marketing mail. A booking confirmation must arrive in seconds and land in the inbox, and it must not be delayed because a campaign damaged the sending reputation.

Everything below assumes transactional sending from an authenticated domain, with delivery events fed back into the application rather than left in a dashboard.

Surface

Capabilities we use

  • Transactional send

    A single API call with recipients, subject, HTML and text bodies, reply to address, attachments and custom headers used for threading and correlation.

  • Component rendered templates

    Emails composed as components and rendered to HTML with a text alternative, so content and application data stay in step and templates are reviewed like code.

  • Batch sending

    Multiple distinct messages in one request, which is useful for a notification fan out without opening a connection per recipient.

  • Domain authentication

    SPF, DKIM and DMARC records configured on a sending subdomain, which is the single largest factor in whether mail reaches the inbox.

  • Delivery events

    Sent, delivered, bounced, complained and opened events delivered by webhook, so the application knows what happened rather than assuming.

  • Scheduled send

    Messages queued for a future time, used for reminders at a defined offset before an appointment.

Data flow

Step by step

  1. 01

    Decide whether to send

    Suppression is checked first: hard bounced addresses, complaints, unsubscribes for the message category, and quiet hours where the message is not urgent.

  2. 02

    Render the message

    The template renders from application data into HTML and a plain text alternative, with every link absolute and tracked only where the recipient has consented.

  3. 03

    Send with a key

    The request carries an idempotency key derived from the record and the message type, so a retry after a timeout does not deliver a second copy.

  4. 04

    Record the attempt

    The provider message identifier is stored against the record before anything else, so a delivery event arriving moments later can be matched.

  5. 05

    Consume delivery events

    The webhook endpoint verifies the signature, stores the event, and updates the message record. A hard bounce adds the address to suppression automatically.

  6. 06

    Surface the outcome

    Delivery state appears on the customer timeline, so a person asking whether the quote was sent gets an answer rather than a guess.

Architecture

How the pieces connect

Transactional email data flow
  1. 01ApplicationtoSuppression store

    check

  2. 02ApplicationtoTemplate renderer

    render

  3. 03Template renderertoResend

    send with key

  4. 04ResendtoRecipient

    deliver. Asynchronous delivery.

  5. 05ResendtoEvent webhook

    events. Asynchronous delivery.

  6. 06Event webhooktoPostgreSQL

    update

  7. 07Event webhooktoSuppression store

    suppress on bounce

Events

Webhooks we handle

  1. email.sent confirming the provider accepted the message
  2. email.delivered confirming the receiving server accepted it
  3. email.bounced, distinguishing hard bounces which suppress from soft bounces which retry
  4. email.complained, which suppresses immediately and should be reviewed
  5. email.opened where tracking is enabled and consent allows it
  6. email.delivery_delayed as an early signal of a reputation or configuration problem

Reliability

What makes it hold

  • Idempotent sending

    A key derived from the record and message type means a retry after a timeout returns the original result. Without it, the most common duplicate email is a successful send whose response was lost.

  • Queue sends outside the request

    Sending happens in a worker, not in the request that triggered it. A slow provider should never slow a checkout or a booking confirmation page.

  • Automatic suppression

    Hard bounces and complaints add to the suppression list without human intervention. Continuing to send to a dead address damages the reputation that carries every other message.

  • Separate sending identities

    Transactional and marketing mail use different subdomains, so a campaign problem cannot stop a receipt arriving.

  • Rate awareness

    Fan out sends are batched and paced rather than fired in parallel, which avoids both provider limits and the spike pattern that filters treat as suspicious.

  • Plain text alternative always

    Every message carries a text part. It improves deliverability and it is what some recipients actually read.

Security

How it is secured

  1. API keys in the platform secret store, scoped per environment, used only in server code.
  2. Webhook signatures verified over the raw body before any processing.
  3. SPF, DKIM and a DMARC policy configured on the sending subdomain.
  4. No sensitive content in an email body where a link to an authenticated page will do.
  5. Personal data in message logs minimised and subject to a retention policy.
  6. Reply addresses routed to a monitored destination rather than a no reply address that discards a customer response.

Evidence

Where we have built this

FAQ

Questions people actually ask

Why not send from our own mail server?

Because deliverability is a reputation problem rather than a technical one. A dedicated provider maintains the sending infrastructure and reputation that decides whether your confirmation reaches the inbox.

What is DMARC and do we need it?

DMARC tells receiving servers what to do with mail claiming to be from your domain that fails authentication. With SPF and DKIM aligned, it protects your domain from being impersonated and improves how your legitimate mail is treated. Yes, you need it.

Should transactional mail go from our main domain?

From a subdomain of it. That keeps authentication aligned while isolating the sending reputation of transactional mail from marketing mail.

How do we know a customer received a quote?

The delivery event is written against the record, so the timeline shows sent and delivered. Opened is available where tracking is enabled and consent allows it, and it is less reliable than people assume.

What happens to a hard bounce?

The address is suppressed automatically and flagged on the customer record so someone can correct it. Repeated sending to a dead address damages delivery for everything else.

Can customers reply?

Yes, and they should be able to. Replies route to a monitored mailbox or into the operational system as a threaded record, rather than to an address that discards them.

Let’s talk about the system you need.

Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.

Discuss Your Projectsupport@sawhorsesoftware.tech
  • A mutual NDA is signed before project details are shared.
  • Scope is fixed in writing before any build starts.
  • You own the source code, the IP and the documentation at delivery.
  • Support plans are available and tailored on a discovery or technical call.