SendlySendly
Migrate from

Migrate from another provider

Move your transactional sending to Sendly by changing two variables in the vendor SDK you already use

Sendly speaks the transactional-send dialect of several popular email providers. If you already send through Resend, SendGrid, Postmark, Mailgun, or Plunk, you don't have to rewrite your integration or adopt a new SDK to try Sendly — keep the vendor SDK you already run and change two things:

  1. the base URL (or host) the SDK points at, and
  2. the API key (use a Sendly secret key — see API Keys).

Everything else — templates, domains, suppression, tracking — you configure in the Sendly UI.

How the compatibility layer works

Each provider gets a dedicated compat endpoint under https://api.sendly.now/api/compat/<vendor>. These endpoints are thin translators: they parse the vendor's request shape, map it onto Sendly's native send, and run it through the same pipeline your native API calls use. That means every Sendly gate still applies — verified-domain checks, sending limits, suppression, and billing — regardless of which dialect you send in.

The compat endpoints cover the transactional send path only. For the full Sendly surface — contacts, campaigns, workflows, templates, webhooks — use the official Sendly SDKs or the API directly.

What happens to features Sendly can't map

A dialect can express things Sendly doesn't support in this phase (scheduled sends, dynamic templates, URL-fetched attachments, and so on). Rather than silently dropping them, the compat endpoint returns a clean error in that vendor's own error shape — so your existing SDK's error handling fires exactly as it would against the original provider. Each provider page below lists precisely what is supported and what returns an error.

Getting a Sendly key

Every request authenticates with a Sendly secret key (sk_...) for a project that has at least one verified sending domain. Create one in your project settings; it slots into the same place the vendor's own key went.

A key with full permissions works across every compat endpoint. If you ticked specific permissions when you created the key, the compat endpoints enforce them exactly as the native API does: sending needs emails:send, and reading a message back — Resend's emails.get(), the one compat call that is not a send — needs emails:read. Reading returns the message's subject, body and recipient, so it follows the same permission rule here as it does natively. A send-only key gets a 403 in that vendor's own error shape, with the message naming the permission it is missing.

On this page