sendvia vs Resend

What each costs at 10,000, 100,000, 500,000 and 1,000,000 emails a month, who owns the sending account, and where Resend is the better buy.

Should I use sendvia or Resend?

Use sendvia if you already run on AWS, want the sending reputation and the Amazon bill to stay in an account you control, and send enough that a flat monthly fee beats a rate per email. Choose Resend if you write your email in React, if you need a delivery confirmation you can act on rather than an assumption, or if you send little enough that its free tier covers you outright. At the extremes neither answer is close. The middle is what the rest of this page is for.

Is sendvia cheaper than Resend?

The two cost the same at 10,000 emails a month. sendvia is cheaper at 100,000, 500,000 and 1,000,000 emails a month.

sendvia is $19.00 a month flat plus Amazon SES at $0.10 per 1,000 emails, billed by Amazon straight to your own account. At 1,000,000 emails that is the flat fee plus $100.00 of SES, and the flat half of it is the half that never moves.

Where a cell says a figure is computed, it is worked out from that provider's own published rate for extra emails on the cheapest plan that can carry the volume, not quoted from a price list. The other three rivals are in the table on purpose: somebody weighing up two of these is usually weighing up more than two, and hiding the rest would make this page less useful rather than more focused.

Feature by feature

Every cell below carries the page it was read from and the date it was read. Where a plain yes or no would mislead, the cell says what the difference actually is instead of rounding it.

Whose AWS account, whose reputation, whose IPs

sendvia sends through an IAM user in your own AWS account. Amazon meters the mail and bills you for it directly, the SES sending identity is yours, and the addresses it leaves from are Amazon's shared SES pool unless you pay Amazon for a dedicated one. Revoke the key and sending stops the same minute, with the verified domains, the DNS records and the bounce history still sitting where they were.

Resend is the other arrangement, and it is the ordinary one. You point a domain at Resend, the mail leaves Resend's servers, and the reputation those servers carry belongs to Resend rather than to you. That is not automatically the worse deal, because whoever owns a pool also polices it and there is somebody whose job is to keep it clean.

What it costs you sits in the DNS setup row above: records added by hand at whatever host holds your domain, with no registrar integration documented, and a second subdomain to verify before opens and clicks are counted at all, since that counting is switched off for every domain until you turn it on. None of it is difficult. It is simply a different set of things to own.

The trade runs both ways, and ours costs you something. You set up the AWS account, you create the IAM user, and a new SES account starts inside Amazon's sandbox, capped at 200 emails a day to verified recipients, until Amazon grants production access.

Does sendvia support SMTP like Resend?

Resend publishes SMTP settings of its own at smtp.resend.com. sendvia runs a relay on smtp.sendvia.io, port 587, with 2525 as a fallback for networks that block it, and your API key is the password.

The send call, side by side

Both are a single POST. Resend takes the same four fields at POST https://api.resend.com/emails, with the API key as a bearer token and the recipients as an array.

curl -X POST https://api.sendvia.io/v1/send \
  -H "Authorization: Bearer sv_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "from":    "[email protected]",
    "to":      "[email protected]",
    "subject": "Your receipt",
    "html":    "<p>Thanks for your order.</p>"
  }'

curl -X POST https://api.resend.com/emails \
  -H "Authorization: Bearer re_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "from":    "[email protected]",
    "to":      ["[email protected]"],
    "subject": "Your receipt",
    "html":    "<p>Thanks for your order.</p>"
  }'

Both answer with JSON and both report a result per recipient. A successful sendvia call comes back as {"success":true,"total":1,"sent":1,"failed":0} plus a results array.

The reply that surprises a reader arriving from a provider which owns the sending account is the 422. sendvia refuses a from-address on a domain it has not verified inside your own SES account, because it has no sending identity of its own to fall back on. Verify the domain and the same call goes through.

# 422 {"error":"The domain \"yourdomain.com\" has not been verified. Add and verify it in the dashboard first."}

The relay takes the same credentials, so the same tool drives it:

curl --url smtp://smtp.sendvia.io:587 \
  --user "sendvia:sv_live_your_api_key" \
  --mail-from [email protected] \
  --mail-rcpt [email protected] \
  --upload-file receipt.eml

Logs and retention

sendvia keeps 7 days of send logs on the free plan and 90 on the paid one, and nulls the stored message body at half the retention period before the row itself is deleted. What it records against a message is a bounce, a complaint, a delivery delay or a rejection, published by SES to an SNS topic in your own account.

Delivery is not on that list, and it is the row to read carefully. sendvia leaves DELIVERY out of its SES subscription because subscribing to it flooded the webhook and stalled the site, so a message with no failure recorded against it two minutes after sending is marked delivered. That is an inference drawn from silence. Resend, Postmark, Mailgun and SendGrid all receive a real delivery event from their own systems, and sendvia does not.

Retention is the row where the table above rewards a close read. Every provider prices it differently, and each cell gives the low and the high across everything that provider publishes rather than the flattering end of either.

Campaigns and lists

sendvia stores contacts, builds segments from rules over their fields and their engagement, imports a CSV with column mapping for exports out of other tools, and sends a newsletter to a list on the same flat fee as the transactional mail. List-Unsubscribe and List-Unsubscribe-Post go on every newsletter send, so the one-click unsubscribe Gmail and Yahoo ask for is there without you configuring it.

Resend calls its equivalent Broadcasts, and a Broadcast is sent to a segment of a stored audience. The table above records what each side holds. The difference that matters here is not capability but where the list lives: on sendvia the contacts sit in the same account as the sending domain and the send log, and there is no separate marketing plan to buy.

What does Resend do better than sendvia?

These come out of the same data file the table above does, and each one links to the page it was checked against.

Who each one is for

Neither line is a slogan. If the one on the left describes you better than the one on the right, the rest of this page is a set of details you do not need.

Can I migrate from Resend to sendvia?

Yes, and most of the work is on the Amazon side rather than in sendvia. You need an AWS account, an IAM user allowed to use SES and SNS, and production access, which Amazon reviews and usually grants within 12 to 24 hours. After that you verify a sending domain, publish the records sendvia generates for it, and import your contacts.

Check what is missing before you start rather than after: there is no dedicated IP option, no inbound email or parsing, no teams or sub-accounts and no official SDKs. If one of those rules sendvia out for you, it rules it out, and better to find that here.

Run both in parallel before you cut over. Send the same traffic through each for a week, compare what lands, and keep the old key alive until you are satisfied. Migrate from Resend to sendvia walks through every one of those steps in order: the AWS setup is the slow part, and everything after it is an afternoon.