Laravel Brevo Notifier Laravel Package

Product Decisions This Supports

• Email vendor selection (build vs. buy): Confirms Brevo as a viable transactional email provider behind Laravel's native notification/mail abstractions. The package is a thin adapter, so the real decision it informs is vendor choice, not integration work — Brevo vs. Postmark/SES/Mailgun/Resend — weighed on pricing model (Brevo's contact/CRM bundling), EU data residency, and deliverability.
• Roadmap: lifecycle and marketing-adjacent email: Release 1.0.3 adds email tags. This is the first feature that meaningfully expands use cases beyond "send transactional mail" toward segmented, attributable messaging — per-tenant tagging, per-product tagging, per-flow tagging (onboarding, receipts, dunning). It makes Brevo's analytics usable from day one instead of requiring custom header plumbing.
• Observability and support tooling: Returning the Brevo API response means message IDs and provider responses are available to the application. This unlocks delivery-status correlation, support workflows ("where is my email?"), and error surfacing in logs — a prerequisite for any product with SLA or support-ticket volume around email.
• Feature prioritization input: Both changes are small, additive, and driven by external contributors — a signal the package is maintained but lean. That argues for scoping email features against the provider's capabilities (templates, A/B, scheduling) rather than expecting the adapter to grow.
• Multi-channel notification architecture: Usable as a Laravel notification channel, so it fits a "one Notification class, many channels" design. Choosing it does not foreclose SMS/CRM via Brevo later.

When to Consider This Package

Consider it when:

• You are on Laravel and already using (or actively evaluating) Brevo as your email provider.
• You want transactional email sent through Laravel's Notification or Mail system with minimal glue code — no custom HTTP client, no hand-rolled API wrapper.
• You need tagging for per-tenant/per-product attribution and reporting (newly supported in 1.0.3), and response/message-ID access for delivery tracking (also new).
• Your team is small and the alternative is 1–2 days of in-house adapter code plus ongoing maintenance.

Look elsewhere when:

• You are not on Laravel, or you are not using Brevo — this is vendor-specific and provides little value as a general pattern.
• You need webhook-driven delivery events (bounces, opens, clicks) processed in-app; the package returns the API response but event ingestion is still your responsibility.
• You require a guaranteed support contract, security review trail, or enterprise SLA. This is a community package with a 1.x version line and volunteer maintainers — treat it as a dependency to pin and audit rather than a vendor relationship.
• You need advanced sending features (batch/campaign APIs, contact-list management, template versioning) — those are Brevo API surfaces the adapter does not expose.
• Your email requirements are heavy enough that an abstraction layer matters more than brevity; a provider-agnostic mailer may reduce switching costs.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk open-source adapter that lets our Laravel application send transactional email through Brevo without custom integration work. The latest release adds two things that matter commercially rather than technically: tagging, which lets us attribute email volume and engagement to specific products, tenants, or customer journeys; and API response access, which gives us message-level tracking for support and deliverability. Net effect: faster time-to-first-email if Brevo is our provider, plus analytics we would otherwise have to build. Cost is a pinned community dependency, not a contract — the trade-off to accept is that we own the operational risk.

To engineering: Adopt it as the transport/channel for Brevo, pin the version, and wrap it. Use tags as the mechanism for per-tenant and per-flow attribution from the start — retrofitting tags onto historical sends is not possible. Persist the returned API response (at minimum the message ID) alongside the notification record so support can reconcile against the Brevo dashboard; do not log the full payload if it contains PII. Note that delivery events (bounces, complaints) are not handled here — plan a webhook receiver as separate work. Treat the 1.x line and volunteer maintenance as a risk: keep the integration behind an interface so a provider swap is a contained change, and review the diff on each minor bump.