Brevo Mailer Laravel Package

Product Decisions This Supports

• Email vendor selection (build vs. buy vs. switch). This package is the cheapest possible way to put Brevo (formerly Sendinblue) into an existing Symfony Mailer / Laravel 9+ mail stack: it is a transport bridge, not an SDK, so the "buy" decision reduces to a vendor contract plus one env var. It directly supports a bake-off between Brevo, SES, Postmark, Mailgun, and SendGrid without code changes — you swap MAILER_DSN and re-run your deliverability tests.
• DSN-as-configuration architecture. Everything the PM needs to promise ("we can change providers in a sprint, not a quarter") is literally true here: brevo+smtp://USER:PASS@default:587 or brevo+api://KEY@default. This is a strong argument for keeping email provider choice out of the roadmap and in ops.
• Feature gating for transactional-email roadmap items. The API transport exposes Brevo's send-transactional-email surface: templateId (server-side templates), params (per-recipient merge data), TagHeader (analytics segmentation), MetadataHeader → X-Mailin-Custom (your own correlation IDs), and sender.ip (dedicated IP routing). That means "use marketing-owned templates without a frontend deploy," "tag mail by tenant/product for reporting," and "route by sending IP" become feature flags rather than engineering epics.
• Migration/rebrand work you can deprioritize. The bridge exists precisely because Sendinblue rebranded to Brevo. If a legacy integration is on the Sendinblue API, this package lets you treat the rebrand as a dependency bump instead of a migration project.
• EU data-residency and cost-sensitivity positioning. Brevo is an EU-headquartered vendor; if a customer segment or a procurement review demands EU processing, this bridge is the low-friction path to satisfy it without re-architecting mail.
• Multi-tenant / per-brand sending. Because transports are DSN-configured per mailer, you can support multiple Brevo accounts (e.g., one per brand or per region) with Symfony's multi-mailer configuration — a product capability, not just an ops detail.

When to Consider This Package

Adopt when:

• Your mail stack is Symfony Mailer (Symfony apps) or Laravel 9+, whose mail layer is Symfony Mailer underneath — but note that Laravel's MailManager uses its own scheme map, so a Laravel adoption requires registering a custom transport that wraps the Symfony one. This is a small but real integration cost, not a drop-in MAILER_DSN edit. Do not let a pitch imply otherwise.
• You specifically want the API transport, not just SMTP — SMTP alone can be done with any provider and does not justify this dependency. The value is templating, tags, custom headers, and IP routing.
• You want vendor choice kept as configuration and are willing to pin exact versions.
• You are already a Symfony shop and value the bridge being maintained under the official symfony/ org namespace, which means it inherits Symfony's release cadence and BC policy rather than a solo maintainer's attention span.

Look elsewhere when:

• Adoption risk matters more than elegance. 26 stars and 0 dependents is a genuine signal: essentially no one has this in production at scale. You would be an early adopter of a thin but unproven-in-the-wild bridge. If email is revenue-critical, weigh that against a dedicated, well-adopted Laravel Brevo package or plain SMTP.
• You need more than sending. This bridge does not do contacts, lists, campaigns, webhooks/event ingestion, suppression management, or inbound parsing. If the roadmap includes deliverability dashboards fed by Brevo events, you need the vendor's API separately — budget for that.
• You are not on Symfony Mailer. Plain PHP, WordPress, Node, or a Laravel app you don't want to touch at the transport layer — a direct HTTP client or SMTP is simpler.
• You need bulk/campaign sending. This is transactional-only by design.
• You need a supported SLA. MIT, community-maintained, "looking for a backer" in the README — there is no commercial support contract here.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed adapter that lets us send transactional email through Brevo — a lower-cost, EU-based provider — by changing one configuration line rather than writing an integration. It keeps us vendor-neutral: if Brevo underperforms on deliverability or pricing, we switch back by editing that same line, with no code rewrite. The strategic value is optionality and negotiating leverage with our current email vendor, not the package itself.

To engineering: It's an official Symfony bridge for Brevo's transactional API and SMTP endpoints, exposing templating (templateId/params), tags, custom headers, and dedicated-IP routing through message headers. Surface area is tiny and it sits on Symfony's standard TransportInterface, so it's easy to abstract or replace. Two caveats to plan around: (1) it is not a Laravel-native package — Laravel's mail manager needs a custom transport registration to use it; (2) it has ~26 stars and zero dependents, so we pin the version, cover it with an integration test against a Brevo sandbox, and treat it as an owned dependency rather than a community one.

The honest risk statement to both: low code risk, moderate adoption risk. We are not betting on the package being clever; we are betting on Symfony's maintenance of a thin adapter. Mitigate with a transport abstraction and a one-day fallback to SMTP if it disappoints.