Notify
Sign in

Migrate from AWS SES to Notify

Replace SES SDK sends with Notify’s HTTP API — keep your HTML, drop the AWS email ops tax.

SES is excellent transport. Notify is the thin DX layer when you do not want to own IAM, SNS bounce topics, and sandbox approval waits. See also Notify vs AWS SES.

What changes

| | AWS SES | Notify | | --- | --- | --- | | Auth | IAM / AWS credentials | x-api-key | | Call shape | SDK SendEmail / SendRawEmail | POST /api/email/send JSON | | Body | Html / Text message parts | Single message field | | Events | SNS / EventBridge / CloudWatch | Logs + webhooks (Pro/Scale) | | Production access | Often sandbox → request production | Verify domain in Notify |

Before / after

SES (AWS SDK v3 sketch)

await ses.send(
  new SendEmailCommand({
    Source: 'noreply@acme.com',
    Destination: { ToAddresses: ['user@example.com'] },
    Message: {
      Subject: { Data: 'Welcome' },
      Body: { Html: { Data: '<h1>Welcome</h1>' } }
    }
  })
);

Notify

await fetch('https://notify.cx/api/email/send', {
  method: 'POST',
  headers: {
    'x-api-key': process.env.NOTIFY_API_KEY!,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    from: 'noreply@acme.com',
    to: 'user@example.com',
    subject: 'Welcome',
    message: '<h1>Welcome</h1>'
  })
});

Migration checklist

  1. Sign up and copy a Notify API key
  2. Verify the same sending domain in Notify (SPF/DKIM)
  3. Replace SES SDK calls with fetch / HTTP
  4. Point bounce/complaint handling at Notify webhooks instead of SNS (Pro/Scale)
  5. Keep SES around only if you still need it for other workloads

When to stay on SES

Very high volume, deep AWS ops maturity, or multi-region SES control where unit cost dominates and you already own logging/webhooks.

Where to next?