Migrate from Elastic Email to Sendar

Map your Elastic Email transactional email workflow, check compatibility and plan a reversible move to Sendar.

Start with one workflow

Inventory the messages your application sends, peak recipient volume, templates, attachments, suppression rules and event consumers. Select one low-volume transactional workflow. Keep the existing integration available until the pilot is verified.

Authentication and transport

Create a Sendar Bearer key instead of reusing your Elastic Email API credentials. Sendar’s customer integration is HTTPS REST. If you only have SMTP configuration access, keep your current relay until your application supports an HTTP adapter.

Before: source message shape

Illustrative Elastic Email message fields, not a complete runnable request. Use the official reference linked below for its current endpoint and authentication.

{
  "Recipients": {
    "To": [
      "reader@example.net"
    ]
  },
  "Content": {
    "From": "hello@example.com",
    "Subject": "Booking confirmed",
    "Body": [
      {
        "ContentType": "HTML",
        "Content": "<p>Your booking is confirmed.</p>"
      }
    ]
  }
}

Map the fields

For the v4 transactional message model, map Recipients.To to to, Content.From to from and Content.Subject to subject. Select HTML and plain-text entries from Content.Body into html and text.

After: Sendar request body

Send this JSON to POST https://sendar.app/api/emails with Authorization: Bearer YOUR_SENDAR_API_KEY. Replace the example addresses with your verified sender and a recipient you control. Use the preview-first starter linked below to inspect a request before sending.

{
  "from": "hello@example.com",
  "to": [
    "reader@example.net"
  ],
  "subject": "Booking confirmed",
  "html": "<p>Your booking is confirmed.</p>"
}

Elastic Email differences to resolve

Check which API version your application uses before adapting it. Campaign audience operations are outside this send migration. Reconcile suppression state and attachment encoding separately.

Sending transport

HTTPS REST API. No customer SMTP relay endpoint is documented. SMTP-only applications need an HTTP adapter or should keep their current relay.

Recipients and headers

The send contract accepts a to array (up to 50 recipients). CC, BCC, Reply-To, arbitrary headers and provider tags are not supported by this contract. Do not silently discard them.

Templates

Create new Sendar templates and map templateId and variables. Variables are strings and missing or unknown keys fail validation. Existing provider template IDs and template engines are not portable.

Attachments

Single sends accept up to five base64 files, with 1.3 MB total decoded content. Use filename, content and optional contentType. URL attachments, inline CID and raw MIME are not supported by this contract.

Events

Sendar exposes sent, failed, scheduled, canceled, bounced, complained, opened and clicked events. There is no per-message delivered webhook. Sent means provider acceptance, not inbox placement.

Scheduling and batches

Scheduling is up to 30 days ahead on Growth and above. Batch sends accept up to 100 messages and do not support attachments or scheduling. Quotas count recipients.

Suppression and retries

Preserve opt-outs, complaints and permanent bounces in your application before cutover. Reconcile both providers during rollback. Do not assume provider suppression lists or idempotency keys transfer.

Verify the domain without disrupting existing mail

Add the exact records shown in Sendar’s Domains page. Preserve current MX records and existing provider DKIM selectors. Do not create a second SPF policy for the same hostname; reconcile authorised senders in one policy with your DNS administrator. Check DKIM signing and DMARC alignment on a controlled received message before cutover.

Pilot, cutover and rollback

First preview the payload locally. When you choose to send a controlled pilot, verify rendering, links, recipients, acceptance status and event handling. Keep a durable application event-to-provider/message-ID record. Route each business event to exactly one provider. On an uncertain timeout, inspect logs before retrying or switching providers. Move a small workflow only after the checks pass; rollback affects future unsent events, not messages already accepted.

Decide whether to switch

Compare peak daily and monthly recipient counts with Sendar’s hard caps and your required capabilities. Retain your existing provider for unsupported workflows. Lower cost, higher delivery rates and complete feature equivalence are not assumed.

Verification scope

Field mappings were reviewed against linked documentation and the Sendar send contract on 2026-10-04. Examples use synthetic data. No live migration, provider account change or email delivery was performed as part of this guide. Test your own integration before moving production traffic.

Reviewed 2026-10-04. Official provider documentation

Sendar pricing · Integration guides