Moving from Resend to getread

What comes with you

• Your domain. Authenticate it with getread alongside your Resend records.
• Your contacts. If you send Broadcasts, bring your contacts over as a CSV.
• Your email code. If you build email with React Email, keep it. You’ll send the HTML it renders.
• Your webhooks. The event names will look familiar.

The request itself will feel familiar too: JSON over HTTPS with a Bearer API key. The main differences are that getread has no SDK and no SMTP relay. If you call resend.emails.send() today, you’ll replace it with a plain HTTPS request, using fetch or whichever HTTP client you already use. If you send through smtp.resend.com, you’ll swap that for the same request.

1. Verify your domain

Add your sending domain in getread. Domain setup walks you through DKIM, SPF and DMARC, shows the exact records for your domain and checks them for you.

• Your Resend records (the resend._domainkey DKIM record and the records on your send subdomain) can stay where they are. getread’s DKIM keys live under their own names, so both providers can sign your email at the same time.
• A domain only ever has one DMARC record. If you already have one, keep your policy and add getread’s reporting address to its rua list.

2. Bring your contacts

If you only send transactional email, your recipients live in your own app, and there’s nothing to move.

If you keep contacts in Resend for Broadcasts, put them in a CSV with email, name and tags, and we’ll help you import them. Keep anyone marked as unsubscribed in a separate file and send that along too, so they stay unsubscribed.

Campaigns only go to contacts with a recorded consent basis, which is how and when they agreed to hear from you. If you know how people joined your list, bring that along as well.

3. Bring your email content

If you build email in code with React Email, keep doing that. Render each email to HTML with React Email’s render() function, then send the result as html. Rendering a plain-text version and sending it as text is a nice touch too.

If you’d rather edit email outside your code, create a saved template in getread and paste in your HTML. Templates use simple variables like {{first_name}} or {{order.number}}, filled in from the attributes you send.

4. Point your send call at getread

Create an API key in getread with permission to send. Then replace your call to Resend’s /emails endpoint with one request to getread:

curl https://app.getread.com/api/v1/transactional/send \
  -H "Authorization: Bearer $GETREAD_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: welcome-user-5521" \
  -d '{
    "from_email": "[email protected]",
    "from_name": "Your brand",
    "to": "[email protected]",
    "subject": "Welcome aboard",
    "html": "<p>We are so glad you are here, Maria.</p>",
    "text": "We are so glad you are here, Maria."
  }'

The Idempotency-Key makes retries safe. Send the same key with the same request, and we return the original message instead of sending it twice.

Here’s how the fields line up:

5. Reconnect your webhooks

getread’s event names will look familiar: email.bounced, email.complained, email.opened and, for campaigns, email.clicked. getread doesn’t track clicks in transactional email. Add a webhook endpoint in getread, choose the events you want, and update your handler to read getread’s payload. Each endpoint gets its own signing secret, so your handler can check that an event really came from getread.

Every event also shows up in Mailroom, so you can see what happened to any message without digging through logs.

6. Run both side by side, then switch

There’s no need to move everything at once. Start with one kind of email, maybe welcome messages, and watch it arrive in Mailroom. When you’re happy, move the rest. Keep your Resend account until everything has moved and the last webhooks have come in, then remove its DNS records whenever you like.

Want a hand with any of this? Talk to us, and a real person will help you plan the move.