# Brevo vs Resend Source: https://wraps.dev/versus/brevo-vs-resend A French all-in-one suite built for a marketer against an API built for one developer's first hour. They overlap on exactly one endpoint and differ on everything surrounding it. Brevo and Resend both send transactional email over an API, and that is roughly where the similarity ends. Brevo is a suite — contacts, campaigns, SMS, a light CRM, automation — sold to a small business that needs marketing to happen. Resend is a sending API sold to a developer who wants the email part of a product finished today. The overlap is one endpoint. Choosing between them means deciding whether your email problem is fundamentally about people who write emails or about code that sends them. ## At a glance |   | Brevo | Resend | | --- | --- | --- | | What it is | EU marketing platform with a transactional API attached | Developer-first email API built on SES | | Published pricing | Priced on send volume rather than contacts. Starter runs from roughly $9/mo at 5,000 emails to roughly $69/mo at 100,000; the Business tier is roughly double at each volume and is where automation and A/B testing live. | 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 | Small EU teams wanting email, SMS, and a light CRM on one invoice. | The fastest path from an empty project to a sent email, especially with React Email. | | Watch out for | The headline tier is not the one you need — automation and removing the Brevo logo are both a step up. Shared-pool deliverability draws mixed reports. | 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 ### The developer experience, honestly assessed Brevo Brevo's API works and nobody describes it as pleasant. The documentation is organised around the suite rather than the sending, the SDKs are generated rather than crafted, and the conceptual overhead of contacts, lists and folders is present whether or not your use case has any. A developer integrating it for transactional mail spends the afternoon on it rather than the hour, and comes away without affection. Resend This is the entire proposition and it delivers. A small SDK, fast domain verification, sensible defaults, error messages that say what is wrong, and React Email maintained first-party. The integration is genuinely done in an hour for a developer who has done it before, and the documentation assumes competence rather than explaining what an API key is. It is the best-in-class experience in this comparison by a distance. ### Marketing capability, equally honestly Brevo Lists, segments, a drag-and-drop designer, scheduling, A/B testing and campaign reporting, all usable by someone who has never opened a terminal. This is a real marketing product with the depth a marketing person expects, and it is the reason Brevo exists. The thing to check is the tier: automation and A/B testing sit above the entry plan, as does removing the Brevo logo from your emails. Resend Broadcasts and an audience concept, which is enough to send an announcement and not enough to run a marketing programme. There is no meaningful automation, no branching, no lifecycle engine. Resend is clear about being a sending product, so this is scope rather than weakness — but a team that needs campaigns will be adding a second vendor, and should price that at the start rather than in month four. ### Where the money goes Brevo Send volume, not stored contacts, which is unusual and genuinely good in this category: a large dormant list does not raise the bill on its own. What raises it is the tier step, which is where the features live. Price the tier that contains what you need rather than the one on the homepage, because that is the most common way an evaluation of this product produces a wrong number. Resend A plan ladder for sending, plus marketing contacts billed separately at a per-block rate. That second charge is contact-based pricing quietly attached to a send-priced product, so a growing audience raises the invoice in a month you sent nothing to it — which is exactly the model Brevo avoided. Two ladders also price the same volume differently depending which you are on, so check which one you are being quoted. ### Europe, and what the requirement actually says Brevo A French company operating in the EU, which answers both the geography and the ownership versions of a residency question. When the requirement comes from a data protection officer rather than an architect, that distinction is frequently the whole evaluation. The consent and preference tooling is built for that regime rather than retrofitted onto it, which shows in the parts of the product concerned with who agreed to what. Resend A US company with published subprocessors and documented data handling, sending through Amazon SES underneath. That is enough for most buyers and it is not a residency guarantee. There is no equivalent of choosing a region and having mail stay inside it. If your requirement is a clause rather than a preference, this dimension ends the comparison rather than informing it. ### Templates and the person who changes them Brevo A visual editor producing templates stored in the platform, editable by a marketer on a Friday with no deploy involved. The HTML it emits is the usual output of a drag-and-drop builder — verbose, and fine. The structural cost is the familiar one: templates are not in version control, not reviewable as code, and reproducing production output locally is harder than it should be. Resend React Email components in your repository, reviewed like any other code, with a preview during development. Better for correctness, versioning and developer sanity, and completely unavailable to anyone who cannot open a pull request. The thing worth knowing is that React Email is not proprietary: it renders to plain HTML that Brevo will happily send, so this benefit is partly separable from the vendor choice. ### The other channels Brevo SMS, WhatsApp, chat and a light CRM alongside email, against one contact record. For a small business that would otherwise run three vendors and reconcile them, the integration is the value even though no individual component is best in class. The CRM in particular is lightweight and is better understood as a contact database with pipeline fields than as a replacement for a real sales tool. Resend Email only, deliberately. There is no SMS, no push, no chat and no contact database beyond what audiences need. If you later need those, they come from other vendors and the joining is yours to do. For a product whose messaging is entirely email, carrying none of that machinery is a benefit rather than a gap. ### Operational risk on each side Brevo Shared sending pools with mixed reports, the usual pattern being that a sender with good engagement is fine and a sender with a purchased list discovers the pool is shared in both directions. Dedicated options exist higher in the range. Brevo is an established company with a long operating history, so the risk here is deliverability variance rather than anything existential. Resend Suspension during traffic spikes is the recurring complaint in its public reviews, following the ordinary shared-pool logic: an unfamiliar surge looks like risk to a platform protecting everyone, and pausing first is the conservative call. Resend is also a young company, which cuts both ways — more attentive support than its size suggests, and less operating history behind the reputation you inherit. ### What you can still answer next quarter Brevo Reporting and contact-level history are retained as part of the suite, which is the natural shape when the product is built around a persistent contact record rather than around individual sends. It is a vendor window on vendor terms, but it is oriented towards the questions a marketer asks about a person over time rather than towards the questions an engineer asks about a request. Resend Thirty days of logs on every plan short of Enterprise, and then the record is gone. That is enough to debug an integration and not enough for a billing dispute, a compliance request or a year-over-year report. Streaming events into your own store from day one fixes it and costs about a day, and almost nobody does it until the first question about last March. ## Pros and cons, side by side ### Brevo Strengths - A real marketing product with lists, segments, a designer, scheduling, A/B testing and reporting, usable by somebody who has never opened a terminal. - The meter reads send volume rather than stored contacts, so a large dormant list is not itself a cost — unusual in this category and genuinely valuable to an occasional sender. - An EU-headquartered company operating in the EU settles the ownership form of a residency question, not merely the geography form. - SMS, chat and a light contact database sit against the same record as the email, which for a small business replaces three subscriptions and the joining between them. Trade-offs - The API works and nobody enjoys it: generated SDKs, documentation organised around the suite, and the conceptual overhead of contacts, lists and folders whether or not your use case has any. - The features people assume are included — automation, A/B testing, removing the vendor's logo from your mail — live above the entry plan, so the quoted price is usually the wrong one. - Templates live in a visual editor outside version control, so reproducing what production actually sent is harder than opening the repository. - Shared pools with mixed reports, where a sender with a purchased list learns that the pool is shared in the direction they did not want. ### Resend Strengths - A small SDK, domain verification that finishes about as fast as DNS does, error messages that say what is wrong, and documentation that assumes competence. - React Email is first-party and maintained, so templates are components under review in your repository — and because it renders to plain HTML, the library outlives the vendor choice. - The product surface is small enough that nobody spends an afternoon choosing between four supported ways to send one message. - A permanent free allowance means a staging environment or a weekend project does not appear on an invoice at all. Trade-offs - Two API requests per second on every tier, unmoved by any upgrade, so a campaign fan-out written as a loop over a list meets a permanent ceiling immediately. - Logs are purged at thirty days on every plan short of Enterprise, which is enough to debug an integration and not enough to answer a question about last quarter. - Marketing contacts bill separately at a per-block rate, which is contact-based pricing quietly attached to a product everyone describes as send-priced. - Suspension during a traffic spike is the recurring complaint in its public reviews, and a young company has less operating history behind the standing you inherit. ## Pick in thirty seconds ### Choose Brevo if - A marketer needs to build, schedule and measure campaigns, and the tooling for that matters more than how the API feels. - A residency requirement was written by a data protection officer, and an EU-headquartered vendor answers it more cleanly than a US one with good documentation. - You want email, SMS and a contact database on one invoice rather than three vendors and a reconciliation. - Send-volume pricing suits you better than paying for contacts who never open anything. ### Choose Resend if - Email is generated by your application and the integration quality is what you will live with every day. - Templates belong in the repository as reviewable components rather than in a vendor's editor. - You do not need campaigns, automation or SMS, and would rather not pay for a suite to use one endpoint. - Time-to-first-send this week is the metric that actually matters, and a permanent free allowance covers the project for now. ## 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. 1. Price both ladders against your actual list before anything else, because the billing models invert here. One side charges for volume and treats a dormant list as free; the other charges for sends and then bills marketing contacts separately in blocks. Moving a large, rarely-mailed list from the first to the second raises the invoice in a month you sent nothing, which is precisely the outcome people choose a send-priced product to avoid. 2. Export the blocklist by reason and work out where the third category lands. Hard bounces, spam complaints and unsubscribes are kept apart on the suite side. On the other side the bounce and complaint record is the vendor's own, and the unsubscribe concept attaches to an audience used for broadcasts rather than to transactional sending. The people who opted out of marketing therefore need a home that is checked before every broadcast, and it is not the same object as the bounce list. 3. Adopt React Email before you commit to anything, because it is separable from the vendor. It renders components to ordinary HTML, and the suite will send that HTML perfectly happily. Doing the template work first turns an all-or-nothing migration into two independent decisions, and it means the migration itself no longer has a rendering rewrite sitting on its critical path. 4. Set up an event destination before the cutover if you report on anything monthly. One side retains contact-level history as a property of being built around a persistent record; the other purges logs at thirty days on every plan short of the top one. A month-over-month report survives that only if the events were already going somewhere you own, and there is no retroactive fix. 5. Count calls per second at peak rather than messages per month. A two-per-second ceiling applies on every tier and does not lift, so a campaign that loops over ten thousand addresses becomes a drip measured in hours. The batch endpoint accepting several recipients per call stretches that a long way, and the send loop has to be written for it from the start rather than refactored the week of a launch. 6. Decide what happens to the non-email channels, because nothing replaces them. SMS, chat and the contact database have no counterpart on the sending-API side, and there is no scope decision pending that will add them. Either those workloads move to a third vendor with its own consent records, or they stop, and the second option needs saying out loud before the suite is cancelled. 7. Re-read the residency requirement if that was ever a factor. One of these is a European company operating in Europe; the other is a US company with published subprocessors and no region selection. If the requirement is a clause rather than a preference, this is not a migration that can be made compliant by configuration, and no amount of good documentation changes that. 8. Split the subdomains and move the traffic in the order of least regret. Transactional mail first, from its own subdomain with its own key, because it is high-engagement and the fastest way to establish standing. Campaigns last, ramped, and never in the weeks around a launch — the pattern that triggers a spike suspension is precisely a large unfamiliar send from a new sender. ## 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. 1. How many contacts do we store versus how many do we mail in a typical month, and which of those two numbers is about to become the billed one? 2. Has anybody counted our peak sends per second, or are we reasoning from a monthly total? 3. Which plan row contains automation, testing and an unbranded template, and is that the row in our comparison? 4. What do we report monthly, and would that report survive a thirty-day retention window? 5. Does our residency requirement name a region or a company, and who wrote it? 6. Who edits marketing copy today, and are they able and willing to open a pull request? 7. If SMS and the contact database went away next month, what breaks and who owns replacing it? ## Common questions ### Can I use Resend for transactional and Brevo for marketing? Yes, and it is the arrangement a lot of teams drift into. Use separate subdomains so DKIM keys, reputation and DMARC alignment stay independent. The real cost is not technical: you now have two suppression lists and two definitions of unsubscribed, and unless one of them is explicitly the owner, somebody who opted out of marketing will eventually receive a campaign. Decide which system holds the truth before you need it to. ### Does Brevo charge per contact? No, and it is the most distinctive thing about its pricing. Brevo charges on send volume rather than stored contacts, so a large dormant list does not raise the bill by itself — the opposite of Klaviyo, Customer.io and Loops. Resend, despite being a sending product, does bill marketing contacts separately from sends. If your list is large and your sending is occasional, that single difference can outweigh everything else on this page. ### Is Resend usable by a non-technical person? Partly. The dashboard shows logs, domains and audiences, and broadcasts can be composed without code. What is not available to a non-technical person is the templates, which are React components in your repository, so any change to what a message looks like requires a developer and a deploy. For a product where a founder wants to iterate on copy quickly, that round trip is the constraint to weigh. ### Which is better for European data residency? Brevo, clearly, if the requirement is written as a clause. It is an EU-headquartered company operating in the EU, which answers the ownership question as well as the geography one. Resend publishes its subprocessors and documents its data handling, which satisfies a great many buyers, but there is no region selection and no equivalent guarantee. This is the one dimension on the page where the answer is not a matter of preference. ### Do I need to pick one? Not necessarily, and the hybrid is common enough to be considered a default rather than a compromise. The most frequent shape is transactional mail on the developer-friendly API and campaigns on the suite, split across subdomains. What that costs you is a reconciliation nobody enjoys and a slightly more complicated answer when someone asks where an email came from. What it buys is each workload on a tool actually designed for it. ### Does the two-per-second limit affect campaigns? Severely, if the send loop was written naively. Ten thousand recipients at two calls a second is well over an hour of drip, and no plan lifts the ceiling. The relief is the batch endpoint, which accepts several recipients in one call and multiplies your effective throughput by whatever that batch size is. The point is that this is a design decision rather than a purchase: write the fan-out against batches on day one, because retrofitting it during the week of a launch is the worst possible time to discover the constraint. ### Can I use React Email without switching vendors? Yes, and doing so is usually the smartest first move. React Email is an open-source library that renders components to plain HTML, and any provider that accepts an HTML body will send the result — including the suite you are currently on. That means the template question and the vendor question are separable: adopt the components, get your templates into version control and under review, and then decide about sending on its own merits rather than as part of a package deal. ### What happens to my marketing contacts when I move? They become a separately billed line, which is the detail that surprises people most. One of these products charges on send volume and treats stored contacts as free; the other charges for sends and then meters marketing contacts in blocks on top. A large list that was costing nothing to keep starts costing something to keep, in a month when the sending did not change. Work out that number from your real contact count before the migration, not from the plan page. ### Which is safer for a big launch send? The established suite, on the narrow question of not being stopped. A young platform protecting a shared pool treats an unfamiliar surge as risk and pauses first, and that complaint recurs in its public reviews. The mitigations are the same either way and they are worth doing regardless: warm a dedicated subdomain for weeks beforehand, start with your most engaged recipients, spread the send over hours rather than minutes, and tell support what is coming before it arrives rather than after.