Brevo: features, costs and workflow fit
A customer communication platform with email and related messaging services. Explore the operating questions and current official sources.
What belongs in the evaluation?
- Which permission covers each recipient?
- Which sender domain is authenticated?
- What distinguishes transactional and marketing messages?
A workflow to reason about.
This is an illustrative planning pattern, not a workflow we have run in this product.
- 01Validate a contact
- 02Check permission
- 03Choose a message type
- 04Record delivery status
Read the current sources.
Compare on your workload.
List the records per run, runs per month, retries, connected services and the person maintaining the process. Separate a vendor’s billing unit from the business result you need.
Use the run-cost planner · Read software cost planning
Start with the kind of message
A newsletter, a password reset and a customer-service reply have different purposes and operating needs. Brevo’s documentation separates marketing, transactional messaging, contact management and webhook events. Map your actual use case to those surfaces before comparing plans. A marketing list should not become a catch-all address book for every person whose email passes through your business.
For a publication, write down the signup source, the subscriber’s permission record, the list they joined and the address that receives replies. Then decide which system owns changes to that record. This is our evaluation framework, not a claim that we have run a production campaign in Brevo.
A small evaluation you can repeat
Use a small set of consenting test contacts with clear labels: a fresh subscriber, an existing subscriber and someone who has unsubscribed. Check how your integration handles each state before scheduling a campaign. Inspect the sender identity and reply-to address, the rendered message, the unsubscribe route and the resulting event record.
In an illustrative test with ten contacts, importing the same ten rows twice should not accidentally create twenty people or send the welcome message twice. Record the identifier used to match contacts and the condition that permits a message. Treat delivery events as delivery events; an accepted API request is not proof that a person read the email.
Check the operating cost, not only the headline plan
List the messages expected each month, the relevant products and the account features you need. Add the time spent maintaining the integration, reviewing failed events and handling contact changes. Compare those assumptions with the current pricing page; no quoted price or guaranteed sending allowance is embedded in this brief.
A useful exit check is to export your own contact and permission records, remove a test contact and confirm which system propagates that change. Keep the domain and consent evidence attached to the publication so the mailing operation can move with it.