Migrating from Amazon SES to Sendpository

Or let your coding agent do the whole migration

Paste it in. It finds every Amazon SES call, rewrites it, updates your webhook handler and switches over behind a flag you can flip back.

ClaudeGrokGeminiCursorCodex

Copy prompt

Show the promptHide the prompt

Switch this project's email from Amazon SES to Sendpository. First run `npx sendpository@latest init` - it opens my browser for me to approve, saves the API key and installs the Sendpository skill - then follow the skill's migration guide (references/migrate.md). If you can't run commands, read https://www.sendpository.com/agents/sendpository/references/migrate.md instead.

1. API differences

2. Authentication differences

3. Domain setup

4. Webhooks

Event names

5. Error handling

6. Code migration

import { SESv2Client, SendEmailCommand } from "@aws-sdk/client-sesv2";

const ses = new SESv2Client({ region: "us-east-1" });

await ses.send(
  new SendEmailCommand({
    FromEmailAddress: "Acme <billing@yourdomain.com>",
    Destination: { ToAddresses: ["customer@example.com"] },
    Content: {
      Simple: {
        Subject: { Data: "Your receipt" },
        Body: { Html: { Data: "<p>Thanks for your order.</p>" } },
      },
    },
    EmailTags: [{ Name: "type", Value: "receipt" }],
    ConfigurationSetName: "transactional",
  }),
);

import { Sendpository, SendpositoryError } from "sendpository";

const sendpository = new Sendpository(process.env.SENDPOSITORY_API_KEY);

try {
  const { id } = await sendpository.emails.send(
    {
      from: "Acme <billing@mail.yourdomain.com>",
      to: ["customer@example.com"],
      subject: "Your receipt",
      html: "<p>Thanks for your order.</p>",
      text: "Thanks for your order.",
      tags: { type: "receipt" },
    },
    // A retried job returns the first message's id instead of sending twice.
    { idempotencyKey: "receipt-10428" },
  );
  console.log(id);
} catch (err) {
  if (err instanceof SendpositoryError) console.error(err.type, err.message);
  throw err;
}

Watch out for

• Your bounce-processing Lambda or queue consumer becomes a webhook handler - and suppression already happens for you, so it may only need to update your own user records.
• Raw MIME sends need to be split into from, to, subject, html, text and attachments.
• Remove the IAM user or role once SES is no longer called, so unused credentials don't linger.

7. Pricing

8. Things to test before switching

• Replace IAM and SigV4 with a bearer token. There is no request signing here and no role to assume - a key in an environment variable is the whole auth model, so anything using an instance profile or STS needs a different secret path.
• Rebuild what Configuration Sets were feeding. SES routes events to SNS, Kinesis Firehose or CloudWatch; ours posts signed webhooks and keeps a searchable log, so any Lambda consuming an SNS topic has nothing to subscribe to after the move.
• Check whether you were in the sandbox. SES accounts start restricted to verified recipients and need a support request to leave; there is no equivalent gate here, which means a test that passed only because SES refused to send will now actually send.

• Send to a real Gmail and a real Outlook address and open Show original: SPF, DKIM and DMARC should all say PASS, with DKIM signed as your own domain.
• Send a message with an attachment and one with an inline image, and check both render.
• Trigger a bounce (an address at a domain you control with no mailbox) and confirm your webhook handler receives email.bounced and marks the address.
• Send the same request twice with one Idempotency-Key and confirm only one email arrives.
• Point a staging environment at the new API key first, and watch the Logs page for 4xx responses before switching production.
• Keep the old provider's DNS records until the new domain has verified and a day of production mail has been delivered - removing them first breaks mail still in flight.

Questions

Keep reading