Migrate from SMTP.com to Sendar
Map your SMTP.com 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
Start by identifying whether your application uses SMTP relay or the SMTP.com API. Keep existing credentials with the old integration; create a separate Sendar key. 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 application model only. This is not a verified SMTP.com API payload.
{
"envelopeFrom": "hello@example.com",
"envelopeTo": [
"reader@example.net"
],
"subject": "Booking confirmed",
"html": "<p>Your booking is confirmed.</p>"
}Map the fields
For an SMTP workflow, map the application’s sender, envelope recipients, subject and rendered body to from, to, subject and html/text. Do not post raw MIME to Sendar. The before example is an application message model, not an SMTP.com API request.
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>"
}SMTP.com differences to resolve
This guide covers SMTP-to-REST planning only. Current SMTP.com API request details could not be independently verified during this review. Confirm channel and API-specific requirements with SMTP.com documentation before implementing an API adapter.
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