Migrate

Switch to Sendara

Moving an established email program is a deliverability event, not a code change. These guides cover the safe way to do it: run Sendara alongside your current provider, import what you already know, and cut over only once the numbers agree.

If you already send through Resend, SendGrid, Postmark, or Mailgun, the API surface you depend on maps onto Sendara almost one-to-one: an API key, a verified sending domain, a send call shaped like { from, to, subject, html }, an event timeline, and webhooks. The hard part of a migration is never the code. It is protecting the reputation you have built. These guides are written around that.

The honest pitch

Sendara is not a magic deliverability upgrade. You send from your own domain with your own DKIM, SPF, and DMARC, so your sending reputation travels with you. A new provider does not reset it, for better or worse. What you get is a clean, predictable API, a full event timeline on every message, idempotent sends, an open suppression model you control, and pricing that does not punish growth. What you should not expect is for a switch alone to fix engagement or list-hygiene problems. If your current numbers are bad, fix the list first. A migration will not.

A warmed-up sending domain stays warm when you change providers, because the warmth lives in your domain's reputation, not the provider's IPs. But if you also change the visible From domain, you are effectively starting fresh. Keep the same sending domain to keep your reputation.

Parallel-run, then cut over

Do not flip 100% of traffic on day one. Every guide here follows the same low-risk sequence, and you can stay at any step as long as you like:

  1. Verify your domain in Sendara. Add it with POST /v1/domains and publish the returned DKIM, SPF, DMARC, and custom MAIL FROM records without removing anything from your old provider. Both can be verified for the same domain at once.
  2. Import your suppression list. Export the bounces, complaints, and unsubscribes your current provider has accumulated and load them into Sendara before the first send, so you never email a known-bad address on day one. See the per-guide steps.
  3. Mirror a slice of traffic. Route a low-stakes stream, such as password resets, receipts, or an internal alert, through Sendara while everything else stays on your old provider. Compare delivered, bounced, and complained rates side by side in the message log.
  4. Ramp. Move more traffic over as the numbers hold. There are no IPs to warm when you keep sending from the same domain, so you can move as fast as your confidence allows.
  5. Cut over and decommission. Point the rest of your traffic at Sendara, keep the old provider verified for a week as a fallback, then turn it off.
Because every send takes an idempotency_key, you can run the two providers behind a feature flag and replay a request against Sendara without fear of double-sending: the same key never sends twice. Look the message up later with GET /v1/messages?idempotency_key=… to confirm it landed.

Per-provider guides

Each guide maps your current provider's concepts, env vars, send call, events, and suppression export onto Sendara's, with before/after code you can paste.

Let an agent do the rote parts

An AI coding agent handles the mechanical edits well: it swaps the SDK import, it renames the environment variable, it reshapes the send payload, and it remaps the webhook event names. Point your agent at the agent guide, or paste the guide below into your agent. The concept map and the before-and-after blocks are machine-readable. You still own the deliverability decisions in the steps above. The agent writes the code.