Move from SendGrid to Relayly

Why teams leave SendGrid

The most common reasons we hear:

• Credits pricing creates surprise bills. Adding a Marketing Campaigns plan on top of the API plan stacks fast.
• Single account region. SendGrid binds your account to one region (typically US). EU compliance teams have to lift-and-shift the entire account to switch.
• Dedicated IPs cost $80/mo extra on top of your plan. Relayly bundles a warming dedicated IP into Pro at $25/mo.
• Twilio account hierarchy doesn't fit a non-Twilio customer's mental model. Sub-accounts behave differently from what most teams expect.
• Marketing Campaigns vs API plan split. Lists, contacts, and templates exist in two parallel worlds depending on which plan you're on.

What carries across

SendGrid concept	Relayly equivalent	Auto-migrates?
Marketing Campaigns Contacts	contacts	Yes — full CSV with custom fields
Lists	lists	Yes — preserves names + opt-in setting
Segments	Predicate-based segments	~80% auto-translate; complex predicates flagged
Suppression Groups	Suppression list (per-tag)	Yes — bounces, unsubs, complaints all carry
Dynamic Templates (Handlebars)	Liquid templates	Most rules auto-translate; we flag the rest with line numbers
API Keys (scoped)	Scoped API keys	Manual recreate (security best practice)
Event Webhooks	HMAC-signed webhooks	Update destination URLs only; payload shape similar
Inbound Parse webhooks	Inbound routes	Yes — same parsed payload shape
Single Sends (campaigns)	Campaigns	Drafts + scheduled migrate; sent history → archive
Automations	Flows	Linear automations migrate; branched logic needs review
Subusers (Twilio account hierarchy)	Sub-accounts	Yes — Scale tier and above

The export — one script

Get a SendGrid API key with full read scope (Settings → API Keys → "Full Access"). Then:

# Install the migration toolkit
curl -fsSL https://relayly.io/migrate/sendgrid-export.sh | bash

# Or directly from the repo
git clone https://github.com/relayly/migrate-sendgrid
cd migrate-sendgrid

export SENDGRID_API_KEY="SG.xxxxxxx"
export RELAYLY_API_KEY="ek_live_xxxxxxx"
export RELAYLY_ACCOUNT_ID="<uuid_from_dashboard>"

python3 sendgrid-to-relayly.py
# ↳ Reads from SendGrid, writes out/<sg_account>/ snapshot
# ↳ Then idempotent POST/SQL into Relayly

The script is read-only against SendGrid — it never mutates your account. Re-runnable safely if interrupted.

The codebase swap

SendGrid's API shape is similar enough to Relayly's that most call sites need only key-name changes. The simplest pattern:

// Before — SendGrid Node SDK
import sgMail from "@sendgrid/mail";
sgMail.setApiKey(process.env.SENDGRID_API_KEY);
await sgMail.send({
  to:      "user@example.com",
  from:    "hello@yourdomain.com",
  subject: "Welcome",
  html:    "<p>Hi</p>",
});

// After — Relayly Node SDK
import Relayly from "@relayly/node";
const relayly = new Relayly({ apiKey: process.env.RELAYLY_API_KEY });
await relayly.email.send({
  to:      [{ email: "user@example.com" }],
  from:    { email: "hello@yourdomain.com" },
  subject: "Welcome",
  html:    "<p>Hi</p>",
});

Find / replace + a one-line shape adjustment. Most CI runs pass on the first try.

SMTP swap (if you don't use the SDK)

Same hostname pattern, just point at us:

# Before
SMTP_HOST=smtp.sendgrid.net
SMTP_PORT=587
SMTP_USERNAME=apikey
SMTP_PASSWORD=SG.xxxxxxx

# After
SMTP_HOST=smtp.relayly.io
SMTP_PORT=587
SMTP_USERNAME=apikey
SMTP_PASSWORD=ek_live_xxxxxxx

No code change — just the env vars.

DNS records

SendGrid asks for CNAME-based domain authentication; Relayly uses TXT records (industry standard). You can run both side-by-side during the cutover — neither set conflicts with the other.

• Keep your existing SendGrid CNAMEs in place during dual-send.
• Add Relayly's three TXT records (SPF append, DKIM esp1._domainkey, DMARC).
• After cutover and the 30-day grace period, remove SendGrid's CNAMEs.

Webhook swap

Relayly's webhook payload is similar but not identical. The main differences:

• Event names: SendGrid uses delivered; we use email.delivered (namespaced).
• Signature header: SendGrid sends two headers (X-Twilio-Email-Event-Webhook-Signature, ...-Timestamp). We send one — X-Relayly-Signature: t=<ts>,v1=<hex>.
• Payload: SendGrid sends an array of events per request. We send one event per request — simpler retry semantics, but if you've coded for batches you'll want a small adapter.

Sample adapter snippet (Node):

// Add at the top of your existing SendGrid webhook handler
function normalize(req) {
  if (req.headers["x-relayly-signature"]) {
    // Wrap a single Relayly event into a SendGrid-shaped batch
    return [{ ...req.body, event: req.body.event.replace("email.", "") }];
  }
  return req.body; // SendGrid path
}

Cutover playbook

1. Day 0 — verify the export. Run the script in dry-run mode (--dry). Review the manifest: contacts, lists, templates, segments. Flag anything missing.
2. Day 1 — apply to Relayly. Run without --dry. Verify in the Relayly dashboard that contacts & templates look right.
3. Day 2 — dual-send week. Send your next campaign through Relayly. Compare inbox-rate at Gmail / O365 / Yahoo (the dashboard exposes this). Repeat for each unique audience type.
4. Day 7 — flip the API key. Search-and-replace your codebase. Deploy. Monitor for 24h.
5. Day 8 — pause SendGrid. Don't delete the account yet — keep it as an unsubscribe-list reciprocity reference for 30 days. Pause all flows + future Single Sends.
6. Day 38 — terminate SendGrid. Cancel the subscription. You're done.

The dual-send overlap question

"Will running both providers for a week tank deliverability?" is the most frequent worry. The honest answer:

• Same recipient receiving the same message from two providers in the same minute will look spammy. Don't do that.
• Different campaigns split across the two providers (e.g., transactional via SendGrid, marketing via Relayly) is fine.
• Most teams cut over a single class of email (transactional first, then marketing a week later) to keep the test surface small.

Pricing-side check

Quick math for a typical migrating team:

Volume	SendGrid	Relayly	Annual savings
50k/mo, no dedicated IP	$19.95/mo	$25/mo	− $60
50k/mo, with dedicated IP	$99.95/mo	$25/mo (IP included)	+ $899
500k/mo, with dedicated IP	$249.95/mo	$100/mo	+ $1,799
1.5M/mo, 2× IPs, EU residency	$629/mo	$130/mo	+ $5,988

SendGrid pricing as of 2026-05 from sendgrid.com/pricing. We're pricier than SendGrid only at the lowest dedicated-IP-free tier — the moment you need one dedicated IP, the math flips.