Migration from Resend

Also migrating from other providers?

• Postmark
• Amazon SES
• SendGrid

If you are moving an existing Resend integration, the Ranla send flow maps closely:

• Bearer API keys
• POST /emails with a familiar JSON body
• Webhooks / activity for delivery outcomes

The main migration steps are:

1. swap the base URL
2. swap your API key to rnl_...
3. verify a sending domain in Ranla
4. update any provider-specific optional fields

Quick mapping

Minimal curl diff

curl -X POST https://api.ranla.ai/emails \
  -H "Authorization: Bearer $RANLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "[email protected]",
    "to": "[email protected]",
    "subject": "Hello",
    "html": "<p>It works.</p>"
  }'

Accepted payload aliases

Ranla accepts a few migration-friendly aliases on the HTTP send API:

• htmlBody or html_body -> html
• textBody, text_body, or plain_body -> text
• replyTo -> reply_to
• scheduledAt -> scheduled_at

Attachment aliases are also accepted:

• filename -> name
• contentType -> content_type
• content -> data
• contentId -> content_id

These aliases are meant to make low-friction migrations easier; new code should still prefer the canonical field names in docs/examples.

Domain verification differences

Unlike provider-managed sandbox products, Ranla expects you to verify your own sending domain for production traffic.

Before DNS is ready, you can still self-test with the shared sandbox sender:

{
  "from": "[email protected]",
  "to": "[email protected]",
  "subject": "Sandbox check",
  "html": "<p>Sandbox works.</p>"
}

Sandbox restriction:

• the sandbox from domain is only allowed when all recipients match the account email on the API key owner

Once your own domain is verified, switch from back to your branded domain.

DNS apply

Ranla can write DNS for you in two ways:

• Cloudflare: save a token once under Settings -> Integrations
• GoDaddy: paste one-time API credentials on the domain detail page, or pass them through the SDK/CLI locally

See docs/api/domains.md.

SMTP

If your old integration still depends on SMTP, create credentials in the dashboard (SMTP) or via POST /smtp-credentials, then connect to smtp.supersendtx.com:587 with username supersendtx. Same verified domains and plan limits as the HTTP API. Prefer POST /emails for new app code. Details: docs/api/smtp.md.