Mailjet Swiftmailer Laravel Package

Product Decisions This Supports

• ESP selection and email infrastructure strategy. If your roadmap includes Mailjet as a transactional email provider, this package enters the conversation as one integration path among several. The PM decision is not "should we use this transport" but "what is our canonical Mailjet integration," and this package is a candidate only for legacy stacks.
• Build vs. buy for email transport. The build side is genuinely cheap here: Mailjet exposes standard SMTP (smtp.mailjet.com, ports 25/465/587), so a vanilla Laravel SMTP mailer is a zero-dependency integration. This package only buys you API-based sending and slightly reduced protocol overhead — a narrow benefit that rarely justifies a third-party abstraction.
• Technical debt triage and migration planning. Last release was 2019-06-13, and its underlying dependency (SwiftMailer) reached end-of-life in November 2021. Any adoption decision is effectively a decision to schedule a migration off of it. This belongs in the debt backlog, not the roadmap.
• Dependency risk review for security and procurement questionnaires. 25 stars and zero dependents means effectively no community review surface: no downstream users to surface regressions, no ecosystem pressure to patch. If a vendor or security review asks "who else depends on this," the answer is nobody — which is a signal, not a comfort.
• Feature scoping for email capabilities. The transport only moves messages. It does not give you Mailjet templating, event/webhook ingestion, bounce and complaint handling, or delivery analytics. Decisions about those capabilities must be scoped separately against the Mailjet API or SDK, and this package should not be credited with enabling them.

When to Consider This Package

Only under a narrow and shrinking set of conditions:

• You are running a legacy Laravel application on SwiftMailer (Laravel 6.x and earlier) and you specifically need Mailjet API-based sending rather than SMTP — for example, hosts that block outbound SMTP ports, or throughput requirements that SMTP cannot meet.
• You are maintaining an existing integration that already uses this transport and it is functioning; in that case treat it as frozen and plan the exit rather than re-evaluating it on merit.
• You need a minimal, MIT-licensed transport with no service contract and accept that you own all maintenance.

Look elsewhere in nearly every other case:

• Laravel 7+ or any Symfony Mailer stack — use the maintained Symfony Mailjet mailer bridge or the official Mailjet API SDK instead. Do not pull SwiftMailer back in.
• Any new project — start with MAIL_MAILER=smtp pointed at Mailjet, or the official mailjet-apiv3-php SDK for API sending. Both are supported by the vendor.
• If you need templates, webhooks, event tracking, inbound routing, or contact management — this transport does none of that; go straight to the Mailjet API/SDK.
• If you need an actively maintained dependency with a support path — the 2019 release date and zero dependents disqualify it.
• If email deliverability and reputation management are core to the product — invest in the ESP relationship and observability, not in a thin transport shim.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed connector that lets a specific legacy PHP framework talk to Mailjet, our email delivery vendor. It is not a strategic component. It was last updated in 2019, its underlying framework reached end-of-life in 2021, and essentially no other projects depend on it. Recommendation: do not adopt it as a new dependency; if it already exists in our codebase, treat it as known technical debt with a scheduled removal, not an outage risk requiring immediate spend.

For engineering: Mailjet speaks plain SMTP, so Laravel's built-in mailer covers most of our needs with zero added dependencies. This package only adds value for API-based sending on pre-Laravel-7 codebases still on SwiftMailer. For anything modern, use the Symfony Mailjet mailer bridge or the vendor's official SDK. If we do inherit this package, pin the version, confirm the Mailjet credentials and fallback path, and add a ticket to migrate before the next major framework upgrade — the blast radius is contained because nothing else in the ecosystem depends on it, which means no one else will be fixing it either.