These two are cross-shopped constantly because they look alike from the outside: modern, developer-first, good documentation, founded by people who clearly disliked the incumbents. Then you use them and they turn out to answer different questions. Loops is a finished product with opinions about how SaaS lifecycle email should work. Resend is a primitive you build on. Their billing units are literally inverted, which is the fastest way to see that they are not competitors so much as neighbours.
At a glance
| Loops | Resend | |
|---|---|---|
| What it is | Product + marketing email for SaaS, priced per contact | Developer-first email API built on SES |
| Published pricing | Free at 1,000 contacts and 4,000 sends/mo. Paid plans price on subscribed contacts with unlimited sends — $49/mo in the 1K–5K band, $99/mo in the 5K–10K band, rising from there. | Free 3,000/mo (100/day). Pro $20 at 50K and $35 at 100K. Scale starts at $90 for the same 100K and runs to $350 at 500K. Overage $0.65–0.90 per 1,000. Marketing contacts billed separately at $40/mo per 5,000. |
| Best for | SaaS teams who want lifecycle and transactional in one tool and never want to count sends again. | The fastest path from an empty project to a sent email, especially with React Email. |
| Watch out for | You pay for contacts, not sends, so a large dormant free list stays on the bill. It is a product rather than a primitive, with less low-level control than an email API. | Logs are purged at 30 days on every non-Enterprise plan, the API is capped at 2 requests per second on all tiers, and suspension during traffic spikes is the complaint that recurs in its public reviews. |
Prices are each vendor's published list prices, verified August 2026. Check the vendor's own page before you sign anything.
Where they actually differ
A product versus a primitive
Loops
Loops has already decided what your lifecycle email looks like. There is a contact record, there are loops that fire on events, there are campaigns, and there is a template editor whose output looks presentable without anyone designing anything. You adopt its model. In exchange you get something running end to end in an afternoon with no architecture decisions to make.
Resend
Resend gives you an API, excellent SDKs, domain verification and a dashboard, and stops there by design. There is no opinion about lifecycle, because lifecycle is your application's business. That is the correct division of responsibility for a lot of teams and it means everything above the send call — scheduling, sequencing, suppression logic, who gets what and when — is code you write.
The billing unit inverts
Loops
Loops bills subscribed contacts and includes unlimited sending. Send your list twice a day and the price does not move. Keep ten thousand people you will never mail and you pay for them every month. The model rewards frequent sending to a curated list and punishes a large dormant one, and there is no volume lever to pull.
Resend
Resend bills sends, with marketing contacts as a separate line item on top. Storing a list you do not mail costs a little; mailing it a lot costs a lot. The model rewards low-volume transactional traffic and gets progressively less friendly as your sending grows, particularly once overage kicks in, which it now does automatically.
Who writes the email
Loops
Loops expects a human to write in its editor, and the editor is good enough that a founder produces a decent-looking announcement without help. Templates live in the product rather than in your repository, which means a copy change does not require a deploy and also means your emails are not in version control.
Resend
Resend expects a developer to write React Email components that live in your repository, reviewed in pull requests and deployed with your application. That is the better engineering story by a distance, and it makes a small copy change a deploy. Which of those two properties you care about more says most of what you need to know about this choice.
Automation and sequencing
Loops
Loops has real lifecycle automation: event-triggered sequences with delays and conditions, aimed at onboarding, trial nudges and winback. It is modest compared to a dedicated lifecycle platform and it is enormously more than nothing, which is what the alternative on this page offers.
Resend
Resend has broadcasts and audiences, and it does not have journeys. A drip sequence is something you build: a scheduled job, a state machine, and your own record of who has received which step. That is a few days of work the first time and a maintenance burden forever, and some teams would genuinely rather own it than configure someone else's canvas.
Throughput and the ceiling
Loops
Loops sends campaigns on your behalf, so its throughput is its problem rather than yours: a blast to a large list is a queue it manages. The corollary is that you have less control over pacing, and for transactional mail you are relying on a product whose primary shape is campaign sending.
Resend
Resend rate limits the API to two requests per second on every plan, Scale included. For request-response transactional traffic that is invisible. For anything that batches — an import, a nightly digest, a migration backfill — it is the constraint you design around, and it does not lift by paying more.
What the logs remember
Loops
Loops keeps a per-contact activity view, which is the right shape for the question a small SaaS actually asks, which is what has this person been sent. It is a product view rather than a forensic log, and it is not the tool you would use to reconstruct an incident across a hundred thousand messages.
Resend
Resend's logs are purged at thirty days on every plan short of Enterprise, and the dashboard is genuinely good inside that window. Past it there is nothing, so if you need a longer record you stream events to your own store from the beginning. The gap is small and it is the single most common complaint about the product.
The dormant list problem, from both sides
Loops
On Loops, a list that stopped converting keeps billing. Because sending is unlimited there is no way to economise except deletion, and deleting contacts is the thing nobody wants to authorise. Teams end up paying a standing charge for an audience they stopped believing in, which is worth naming before you sign up rather than after.
Resend
On Resend, the equivalent is subtler: marketing contacts bill separately from sends, so the same dormant list shows up as a line you might not have connected to your list size. The difference is that you can stop mailing it and the sending side of the bill genuinely falls, which makes the problem cheaper to ignore and therefore easier to leave unfixed.
Handling an unsubscribe
Loops
Loops manages subscription state as part of being a product: a preference page exists, the unsubscribe link is handled, and a contact who opts out stops receiving campaigns without you writing anything. For a team with no compliance specialist, having that path correct by default removes a genuine legal risk rather than a chore.
Resend
Resend gives you the primitives — an unsubscribe header, a broadcast audience with subscription state — and the responsibility. If you are sending marketing mail from your own sequencing code, honouring an opt-out across every message type is logic you own, and getting it subtly wrong is both an inbox-placement problem and a regulatory one.
Pros and cons, side by side
Loops
Strengths
- Lifecycle sequencing exists as a product, so the third message of an onboarding series is a delay somebody configured rather than a durable timer somebody is on call for.
- Subscription state, the preference page and the unsubscribe link are all handled, which removes a genuine legal exposure from a team that has no compliance specialist on it.
- The output looks presentable with nobody designing anything, which for a team of four is worth considerably more than templating power they were never going to use.
- The receipt, the onboarding nudge and the monthly update all reach one contact record, so there is exactly one answer to what has this person been sent.
Trade-offs
- Templates exist only as state inside the product, so there is no diff, no review before a change goes live, and no way to stand up an environment by running something.
- There is no relay endpoint at all, so anything in the estate that can only be handed a hostname and a password needs a permanent home somewhere else.
- Unlimited sending removes the natural brake, so a runaway trigger has nothing between it and your entire list except a guard rail somebody remembered to build.
- The meter counts people you keep rather than mail you send, so the only way to spend less is to delete somebody, and nobody wants to be the person who authorised that.
Resend
Strengths
- Templates are components in the repository, so a copy change is reviewed, versioned, and deployed to a staging environment by running the same command as everything else.
- There is a relay endpoint, so the legacy system nobody intends to rewrite has somewhere to go without a third supplier appearing on the estate.
- A hard request ceiling is an unglamorous accidental circuit breaker: a runaway loop drips instead of emptying your list before anybody has woken up.
- You are not paying for people you are merely storing, so a large list that is rarely mailed costs approximately what mailing it costs and nothing besides.
Trade-offs
- There are no journeys, so a three-step onboarding sequence becomes durable timers, per-person state and an exit condition that somebody operates from now on.
- Two requests per second holds on every plan, so any cohort that becomes eligible at the same moment is a queue rather than a loop over a list.
- Logs vanish at thirty days below Enterprise, so the record of what you sent is only as long as the pipeline you thought to build before you needed it.
- Audience members are a separate population from your users, and nothing keeps the two honest with each other unless you write the thing that does.
Pick in thirty seconds
Choose Loops if
- You want lifecycle email working this week without designing a sequencing system yourself.
- Non-engineers will write and send some of the mail, and waiting on a deploy for a copy change is not acceptable.
- You mail your list often, so unlimited sending on a per-contact price is straightforwardly good value.
- One tool for product announcements, onboarding sequences and transactional mail is worth more than best-in-class at any one of them.
Choose Resend if
- Your email is transactional and your application already knows who to send what and when.
- You want templates as React components in your repository, versioned and reviewed like the rest of your code.
- You expect to build your own sequencing, and you would rather own that logic than express it in someone else's canvas.
- Your list is large and rarely mailed, so paying per send beats paying per stored contact.
What actually moves when you switch
In roughly the order you would do it. The expensive parts of an email migration are never the send call.
- Work out how a template reaches a new environment, because only one side answers that with code. Messages authored inside a product exist as state in that product: no file, no diff, no way to provision a staging account by running something, and no review standing between an edit and a customer. Teams used to opening a pull request discover this the evening somebody changes live copy at five o'clock, and the remedy is a process with a named owner rather than a feature request.
- Decide what identifies a person before importing anybody, because one side keys on the address itself. When a customer changes their email, a system keyed that way either acquires a second person or needs to be told explicitly, and every property and subscription state hangs off whichever record it settled on. Find out what your own application does today when somebody updates their address, then make the messaging side do the same thing on purpose rather than by coincidence.
- Notice which side has an accidental circuit breaker and which does not. A hard request ceiling is an irritation for a batch job and it is also the thing that stops a bug mailing your entire list inside ninety seconds. Unlimited sending removes the irritation and the brake together, so the guard rail becomes something you build: a cap per run, an alert on volume, a confirmation before anything addresses more than a few thousand people. Nobody builds it before the first incident.
- Price the sequencing honestly if you are moving toward the primitive, because wait three days is a durable timer rather than a sleep. Somebody owns what happens when a deploy restarts mid-sequence, when a person qualifies twice, when the condition that held on Monday no longer holds on Thursday, and when a step fails halfway through a cohort. That is a few days to build and a standing obligation to operate, and the second half is what every estimate leaves out.
- Settle where the authoritative record of a person lives, because the primitive hands you an audience object that is not your user table. Campaign recipients become rows in the vendor's audience carrying their own subscription state while your application keeps its own users, and nothing reconciles them. Decide which side wins a conflict and write the synchronisation before the first broadcast rather than after somebody has unsubscribed twice and still hears from you.
- Check whether anything in your estate needs a hostname and a password, because this pair is unusual in that the primitive has a relay and the finished product does not. A content system, a monitoring agent or an invoicing tool that speaks only the protocol can be pointed at an endpoint in one direction and is simply not travelling in the other. That is a second vendor and a second subdomain going one way and a solved problem going the other, and neither vendor's comparison page mentions it.
- Establish who controls the rate a campaign actually leaves at. Sending on your behalf means the vendor queues and paces a blast while you watch; sending it yourself means you decide, which sounds preferable until forty thousand people become eligible at nine in the morning. Neither arrangement is wrong, and only one of them lets you slow down deliberately for a receiving domain that has started deferring you an hour into the run.
- Inventory the places your application tells the messaging system that something happened, because those call sites are the migration. A product reacts to events you post; a primitive reacts to nothing, so the decision to send moves back into your code along with the duty to make it happen exactly once. Travelling the other way, code that called a send endpoint directly becomes code that posts an event and trusts that somebody has built the sequence which consumes it.
Questions to ask before you sign
Put these to a sales rep, or find the answer in the documentation before anyone quotes you a number.
- How would we stand up a staging environment containing our real templates, and does that involve a person clicking through an editor?
- What happens in our system today when a customer changes their email address, and would the messaging side agree with it?
- If a bug fired a sequence for every contact at once, what would stop it, and how long would it take anybody to notice?
- Who owns the durable timers if we build the sequencing ourselves, and are those people on call for them at the weekend?
- Which record of a person is authoritative once this is running, and has anybody written that decision down?
- Is anything in our estate only capable of sending by being given a hostname, a port and a password?
- When a receiving domain starts deferring us an hour into a campaign, who here is able to slow the send down?
Common questions
Can Resend do drip campaigns?
Not as a product feature. It has broadcasts and audiences, which cover sending a message to a list, but there are no journeys, delays or conditional branches. A drip sequence on Resend is a scheduled job in your application plus your own record of who is at which step. That is ordinary work, and it is work — usually a few days initially and a permanent maintenance obligation after.
Does Loops handle transactional email as well as Resend?
It handles it, on the same templates and the same reputation as your marketing mail, which is a real convenience for a small team. Resend is the more focused transactional tool: better SDK ergonomics, idempotency behaviour you can reason about, and a dashboard built for debugging a single message. Whether that focus is worth a second vendor depends on how much transactional mail you send.
Which is cheaper?
Depends entirely on the ratio between your list size and your send volume. A big list mailed rarely is cheaper on Resend; a small list mailed constantly is cheaper on Loops. Work out both numbers for your actual usage, and on Resend remember to add marketing contacts as a separate line rather than assuming they are included in the sending plan.
Can I use React Email with Loops?
Not as the native authoring path. Loops expects its own editor, which is the point of the product: a non-engineer can change an email without a deploy. If having templates as components in your repository is a requirement rather than a preference, that requirement is pointing you at Resend, and it is a reasonable thing to let decide the question.
Is Resend's two requests per second limit really on every plan?
Yes, including Scale. For request-response mail it never comes up. For anything batched you queue and drip, which is fine and is also an architectural constraint you should know about before you build. The relevant question is whether anything in your system ever wants to send thousands of messages in a short window, because if so the design has to account for it from the start.
Could I run both at once?
Yes, and unlike most pairings on this site it is a defensible architecture, because they overlap so little: Resend for transactional mail triggered by your application, Loops for campaigns and onboarding sequences a human curates. Two things to get right. Send them from different subdomains so a marketing complaint rate cannot reach the reputation your password resets depend on, and pick one system as authoritative for subscription state so an unsubscribe in one is honoured by the other. Neither is hard, and neither happens by itself.
Can I keep Loops templates in version control?
Not in any way that makes the repository authoritative. The editor is where messages live, and what is in it is the thing that gets sent, so any copy you keep alongside your code is a copy rather than a source. Teams who care about this end up with one of two arrangements. Either they accept it and put a human process around the editor — a second pair of eyes before anything goes live, a note in the changelog, a convention that nobody edits production copy after four o'clock — or they conclude that authored-in-a-product is a requirement they cannot meet and that conclusion settles the comparison. Which of those you are depends less on how much you like pull requests than on whether an unreviewed wording change reaching customers is an inconvenience or an incident in your business.
What stops a bug from mailing my whole list?
On one side, a rate ceiling nobody chose for that reason. Two requests a second is genuinely annoying for batch work and it is also the reason a runaway loop drips rather than emptying a list of eighty thousand people before anybody is awake — you get hours of warning instead of minutes. Unlimited sending removes the annoyance and the accidental protection in the same stroke, which means the brake has to be deliberate. The cheap version is three things: a hard cap on how many recipients any single run may address, an alert that fires on volume rather than on errors, and a confirmation step in front of anything that would reach more than a few thousand people. None of it is clever and all of it gets built after the first incident rather than before, which is what makes the incident expensive.
Does Resend have an SMTP endpoint?
Yes, and it is one of the more consequential differences between these two that nobody puts on a comparison table. Resend accepts a relay connection, so a content management system, a monitoring agent, an invoicing tool or any of the other software in an estate that only knows how to be given a hostname, a port and a password has somewhere to go. Loops is an API and an interface, built on the premise that the thing sending is your own product, and there is no endpoint for that traffic at all. If you have even two or three such systems, the choice is not really between these two products — it is between one product and one product plus a relay vendor, with the second subdomain and second set of credentials that implies. Count those senders before pricing anything, because the count is reliably higher than the first pass found.