Weave Code
Brevo Mailer Laravel Package
symfony/brevo-mailer
Brevo (formerly Sendinblue) mailer integration for Symfony Mailer, supporting SMTP and API transports plus custom headers for templates, tags, params, and metadata.
Symfony Brevo Mailer Bridge
Frequently asked questions about Brevo Mailer
- How do I use symfony/brevo-mailer in a Laravel application?
- Laravel's MailManager is a thin configuration layer over Symfony Mailer and resolves Symfony\Component\Mailer\Transport\TransportInterface instances, so the bridge's transports drop in directly. The one piece Laravel does not consume natively is the DSN factory, so you add roughly 30 lines of glue in a service provider: Mail::extend('brevo', fn (array $config) => (new BrevoTransportFactory())->create(new Dsn($config['dsn']))). Then add a brevo mailer entry to config/mail.php and route specific mailables with Mail::mailer('brevo') so rollback is a config flip rather than a deploy. You cannot use MAILER_DSN=brevo+api://KEY@default out of the box, because Laravel's mail config is array-based rather than DSN-based.
- Which Laravel and Symfony versions does symfony/brevo-mailer support?
- The bridge is released in lockstep with Symfony and requires PHP 8.1+ plus symfony/mailer ^6.4 or ^7.0. Laravel 9 and 10 run on Symfony 6, while Laravel 11 and 12 run on Symfony 7, so pin the bridge branch that matches the Symfony family your Laravel version resolves. A mismatch there is the single most likely Composer failure with this package; run composer why-not symfony/brevo-mailer to see the exact constraint conflict instead of guessing.
- How do I install symfony/brevo-mailer with Composer?
- Run composer require symfony/brevo-mailer and let Composer pick the branch matching your installed Symfony major. If it fails, check constraints with composer why-not symfony/brevo-mailer first, then pin an explicit version such as ^6.4 or ^7.0. There is no Laravel package auto-discovery here, so the transport registration in a service provider is entirely your own code.
- What is the difference between the brevo+api:// and brevo+smtp:// transports?
- brevo+api://KEY@default sends over Brevo's HTTP /v3/smtp/email endpoint using symfony/http-client, and it is the only variant that supports Brevo features like templateId, params, tags, sender.ip and X-Mailin-Custom. brevo+smtp://USERNAME:PASSWORD@default wraps Symfony's EsmtpTransport, defaulting to port 465 with implicit TLS; on any other port the connection starts in clear text and upgrades via STARTTLS when the server offers it. If you only need to deliver a fully rendered HTML body, the SMTP variant adds nothing over Laravel's stock smtp mailer.
- Do I need symfony/brevo-mailer if I only send transactional mail through Brevo SMTP?
- No. Point Laravel's built-in smtp mailer at Brevo's SMTP host with your credentials and you get the same deliverability, DKIM/SPF alignment and bounce handling with zero new dependencies. The bridge only earns its place when you need the API transport: server-side templates, params, tags, or per-send metadata and IP selection. Staying on the stock mailer also avoids owning a dependency through any future Brevo rebrand or API deprecation.
- How do I send Brevo templates, tags, params, and custom headers from Laravel?
- Use the API transport and add Symfony Mime headers to the Email before sending: MetadataHeader for the X-Mailin-Custom JSON, TagHeader for tags, a text header named templateId, and ParameterizedHeader for params. Sender IP and other arbitrary values go through addTextHeader, for example sender.ip. These headers are only meaningful on the API transport, so they are ignored if you send over brevo+smtp://.
- Why does my Brevo API send fail with a generic TransportException?
- Symfony maps HTTP failures to TransportException, so Brevo's 400-level template and parameter errors arrive as a generic send failure with no useful message. Unwrap the exception's previous chain to get the ResponseInterface and read Brevo's JSON error body, which names the offending field. Budget for that wrapper in your error handling and logging, otherwise diagnosing template mistakes in production is painful.
- Where should I store the Brevo API key in a Laravel app?
- Keep it in your .env or a secret manager, never hardcoded in config/mail.php, because the DSN string embeds the credential and config files get committed. Reference it from config/mail.php with env() so the value is baked into the cached config, and read it with config() inside your Mail::extend closure rather than calling env() there, which returns null once config is cached. Run php artisan config:clear after changing the key, or the stale DSN will keep being used.
- Is 26 GitHub stars and zero dependents a sign that symfony/brevo-mailer is abandoned?
- No. Bridges like this are subtree splits of the Symfony monorepo, maintained inside the Symfony organization, MIT licensed and released in lockstep with Symfony itself. Adoption flows through symfony/* version constraints rather than standalone Packagist installs, so stars and dependents are a low-signal health metric here. Judge it instead by its tiny surface area: one transport factory plus two stateless transports, with no migrations or schema.
- Should I use symfony/brevo-mailer or Brevo's own PHP SDK?
- The bridge keeps you inside Symfony Mailer and therefore inside Laravel's Mail facade, Mail::fake() testing and your existing mailables, which is a real advantage over hand-rolling the Brevo SDK. The official SDK covers broader Brevo features such as contacts and campaigns that a transactional mailer bridge deliberately omits. If Brevo might be swapped for Postmark or SES in 18 months, weigh whether the small DSN abstraction and service-provider glue are worth owning, or whether a config-only SMTP setup keeps your exit cost near zero.
Weaver
How can I help you explore Laravel packages today?