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:
- the base URL (or host) the SDK points at, and
- the API key (use a Sendly secret key — see API Keys).
Everything else — templates, domains, suppression, tracking — you configure in the Sendly UI.
Resend
Point the resend SDK (JS or Python) at Sendly.
SendGrid
Point @sendgrid/mail (JS) or sendgrid (Python) at Sendly.
Postmark
Point the postmark SDK at Sendly with a request-host override.
Mailgun
Point mailgun.js at Sendly with a URL override.
Plunk
Sendly's ancestral API — a near drop-in for existing Plunk senders.
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.
Model Context Protocol
The open protocol an AI agent uses to work in your Sendly account, and the permission model around it
Migrate from Resend to Sendly
Keep the official Resend SDK for JavaScript or Python. Point it at Sendly's Resend-compatible API by changing the base URL and API key, and see which fields carry over.