Headoo Mailjet Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for transactional email. The only real decision this package surfaces is whether a thin framework wrapper around a vendor SDK is worth owning. It isn't — the wrapper's entire value is "instantiate the Mailjet client and read two config keys," which is 50–100 lines of glue we can own outright. This package is the "buy" option with all of the buy's downsides and none of its support.

• Provider portability / lock-in strategy. The defensible position is a narrow TransactionalMailer interface (send, template vars, bounce/webhook hooks) with Mailjet as one implementation. Swapping ESPs later should be a one-file change, not a migration project. This package embeds Mailjet at the framework layer, which is exactly the place you don't want a provider dependency.

• Deprecation triage and technical-debt prioritization. Deprecated, 3 stars, 0 dependents. That combination is a product signal, not a curiosity: if anything we run depends on it, it belongs on the debt backlog with an owner and a removal date — not a "monitor and revisit" label. Zero dependents also means no downstream project has validated it against a current PHP/Symfony runtime; we'd be first, with no prior art.

• Stack-fit gate. Despite being filed as a Laravel/PHP package, this is a Symfony bundle (type: symfony-bundle, DI extension, services.yml, no ServiceProvider, no facade). The brief says Laravel. That mismatch alone disqualifies it before quality is even considered — Composer will install it, but Laravel's package discovery registers nothing.

• Roadmap input for deliverability work. Bounce handling, complaint webhooks, multi-provider failover, and 429/rate-limit queueing are all our mailer-configuration work. None of it lives in this bundle, so none of it should be scoped as "blocked on the package."

• Use cases it nominally serves: password resets, welcome/onboarding sequences, receipts and transactional notifications — one recipient, one HTML body, sent through Mailjet's API. All of them are better served by the official SDK behind a queue.

When to Consider This Package

Adoption criteria — all must hold, and realistically they won't:

• You maintain a legacy Symfony 2.x/3.x application already wired to this bundle's service definitions and config tree, and ripping it out costs more than a sprint.
• You need Mailjet's API and genuinely cannot upgrade to a Symfony version with a first-party Mailjet transport.
• You accept no security patches, no PHP 8.x guarantees, and no upstream support path.
• A named engineer owns it, with a one-page runbook and a written removal date.

Look elsewhere in essentially every other case:

• New Laravel work: use mailjet/laravel-mailjet if you want a maintained bridge, or — better — the official mailjet/mailjet-apiv3-php SDK behind your own TransactionalMailer bound in a service provider, dispatched through a queued job with $tries = 3 and backoff.
• Modern Symfony (6.4+/7): use symfony/mailer with the first-party Mailjet transport. Maintained, covered by Symfony's security process.
• Porting logic out of an inherited Symfony app: read the bundle's client class for the payload shape, then reimplement against /v3.1/send yourself. Don't carry the dependency across.

Red flags that end the conversation: deprecated status, negligible adoption, zero dependents, and a framework mismatch against the stack in the brief. Also verify before any experiment whether its composer.json caps PHP/Symfony below our runtime — and never force-install with --ignore-platform-reqs, which converts a visible install failure into silent runtime drift.

How to Pitch It (Stakeholders)

For executives. This package is deprecated, has three stars, and zero downstream dependents — no community, no maintainer, no security response path. It is not a candidate for adoption. The only decision it should trigger is a one-time check: does anything we run already depend on it, and if so, when do we migrate off? Financial exposure is small and bounded — replacing it with a maintained alternative is roughly one to two engineer-days — against an unbounded risk of an unpatched dependency sitting directly in our outbound mail path, where a silent failure means password resets and receipts stop arriving.

For engineering. Do not add this to any new codebase. It is a Symfony bundle, not a Laravel package: Composer installs it, Laravel's discovery registers nothing, and you'd be writing the service provider yourself around unmaintained code. The requirement was never "integrate this bundle" — it's "deliver transactional email via Mailjet," which is solved by the official SDK behind a narrow TransactionalMailer interface and a queued job, or by registering Mailjet as a custom Symfony Mailer transport (Laravel's mail layer sits on Symfony Mailer). Both paths are ~50–100 lines of glue we own, both track current PHP, and neither drags a dead dependency tree into our lockfile.

If something already depends on it: inventory actual usage, volumes, and webhook consumers first — the classic failure is removing the "unused" bundle and discovering a bounce-webhook route pointed at it. Then introduce the interface at the call sites, run a Mailjet-SDK-backed implementation alongside, cut over by config flag, verify delivery plus bounce/complaint handling in parallel, and delete the package. Pin the current version as an interim control, name an owner, and record the decision.

Bottom line. No adoption. Possible remediation work on existing usage. Low urgency, low cost, real but modest risk — and the cheapest moment to deal with it is now, while it's a day of work rather than an incident.