Sendly vs Resend

The short version

Resend is a transactional email API for developers. If sending receipts, password resets and notifications from your application is the whole job, it is a focused tool for exactly that job.

Sendly starts from the same place — a REST API for transactional email, typed SDKs, webhooks — and keeps going: marketing campaigns, a visual workflow builder, dynamic segments, real inbound mailboxes, and an MCP server for AI agents, all against one contact database and one bill.

The practical question is not which API sends mail better. It is whether your marketing email is going to live in a second product, with a second contact list, a second suppression list and a second invoice. If it already does, that is the thing Sendly removes.

Moving from Resend takes two variables

Sendly speaks Resend's transactional-send dialect on a dedicated endpoint at /api/compat/resend. Keep the Resend SDK you already run, point it at Sendly, and swap the key. There is no rewrite and no second client library.

The endpoint is a translator, not a side door. It parses the vendor request shape, maps it onto Sendly's native send, and runs it through the same pipeline your native API calls use — so verified-domain checks, sending limits, suppression and billing all still apply.

Where a dialect can express something Sendly does not support in this phase, the endpoint returns a clean error in that vendor's own error shape rather than dropping the field silently. Your existing error handling fires exactly as it would have.

In practice that is a base URL and an API key in your environment. The Resend SDK, your call sites, your templates in code and your error handling stay exactly as they are.

import { Resend } from "resend";

const resend = new Resend(process.env.SENDLY_API_KEY, {
  baseUrl: "https://api.sendly.now/api/compat/resend",
});

// unchanged from here down
await resend.emails.send({
  from: "hello@yourdomain.com",
  to: "customer@example.com",
  subject: "Your receipt",
  html: "<p>Thanks for your order.</p>",
});

One call is not a send and is worth knowing about: emails.get() reads a message back, including its subject, body and recipient. It needs the emails:read permission on your key, exactly as the equivalent native call does. A send-only key gets a 403 in Resend's own error shape, naming the permission it is missing.

What Sendly does

Sendly is one workspace for transactional email, marketing campaigns and automation, against one contact database. Everything below is in the product today, not on a roadmap.

What Sendly costs

There is no monthly platform fee and there is no plan to outgrow. A free tier, metered usage that gets cheaper as volume rises, and a conversation for anything past that.

The free tier is a real tier, not a trial: it does not expire, and nothing about it is time-limited. Its allowance is shared across transactional sends, campaigns, workflows and inbound mail, because Sendly meters emails rather than products.

What to check on Resend's side

We do not publish Resend's prices or limits here. They change without telling us, and a stale number on this page would be the one thing on it you could catch us being wrong about. These are the questions worth answering from their own documentation before you move anything.

• What does the bill look like at your actual monthly volume, and at ten times it? Flat plans and metered curves cross over somewhere; find where.
• Are transactional sends and marketing sends billed and rate-limited from the same allowance, or two?
• Is there a contact-count charge on top of the send charge, and does an unsubscribed contact still count?
• What happens on the day you exceed the plan — a hard stop, an overage rate, or an upgrade prompt?
• Can you export your contacts, templates and suppression list in full, without asking support?
• Is there an API for everything the dashboard can do, and is the contract published?

Questions people ask

Can I keep the Resend SDK?

Yes. That is the point of the compat endpoint. Both the JavaScript and the Python Resend SDKs accept a base URL, so pointing them at https://api.sendly.now/api/compat/resend and supplying a Sendly secret key is the entire change. The JavaScript SDK also reads RESEND_BASE_URL and the Python one reads RESEND_API_URL, so it can be done without touching code at all.

Do I have to migrate everything at once?

No. The compat endpoint is a normal API endpoint, so you can move one service, one environment, or one message type at a time and leave the rest where it is. Nothing about running both in parallel is special-cased.

Does the compat endpoint skip any of Sendly's checks?

No. It parses the Resend request shape and then runs the same pipeline a native Sendly send runs: verified-domain checks, sending limits, suppression and billing all apply. It is a translator, not a bypass.

What happens to a Resend feature Sendly does not support?

The endpoint returns a clean error in Resend's own error shape, naming what it could not do, rather than accepting the request and quietly dropping the field. Your existing error handling fires the way it already does.

Do I need a Sendly domain verified before I can send?

Yes, the same as anywhere else. Sending requires a verified domain on the project the key belongs to. Guided DNS setup can publish the records for you and then watch them, so verification is usually a few minutes rather than a ticket.