Mailjet Mailer Laravel Package

Product Decisions This Supports

• Transactional email delivery channel: backs any user-facing email flow (password resets, receipts, invites, notifications, alerts) by plugging Mailjet's HTTP API into Symfony Mailer as a first-class transport — a single line of config (mailer://mailjet+api://KEY:SECRET@default) rather than custom curl code.
• ESP selection / re-evaluation: makes "which email provider" a reversible, low-cost decision. If Mailjet pricing, deliverability, or regional data requirements change, swapping transports is a config change, not a refactor — a strong argument for keeping sending behind the framework's mailer abstraction.
• Build vs. buy: this is a "buy the glue" decision. The bridge is ~a thin adapter maintained upstream; writing and maintaining your own Mailjet API client is pure cost with no product differentiation. Build only if you need Mailjet capabilities the bridge doesn't expose.
• Roadmap fit for Mailjet's broader platform: relevant if your roadmap includes Mailjet templates, tagging/categories for analytics, or webhook-driven bounce/complaint handling. The bridge covers sending; anything contact-list, campaign, or event-feedback oriented likely needs the Mailjet SDK or direct API work as separate scope.
• Async / throughput work: integrates with Symfony Messenger when you need queued sending and retries, so it factors into scaling decisions (bulk notifications, digest emails) rather than blocking request cycles.
• Framework-fit decision: primarily a Symfony (and Symfony-Mailer-based) asset. In Laravel it is not a drop-in native mailer — Laravel's mail manager needs a custom transport registration to use a Symfony transport. That's a real adoption cost to weigh against Laravel's built-in Mailgun/Postmark/SES/SMTP mailers.

When to Consider This Package

Consider it when:

• Your app already sends mail through Symfony Mailer (Symfony app, or Laravel wired to Symfony Mailer transports) and you want Mailjet as the delivery path.
• You want API-based sending rather than SMTP — better latency, clearer error responses, no port/relay constraints in restricted hosting environments.
• You already have a Mailjet account, verified sender domains, and API credentials, or Mailjet is already the commercial choice.
• You value upstream maintenance and MIT licensing over raw popularity — the low star count reflects a narrow bridge, not neglect; release cadence tracks Symfony Mailer.
• You need queued/async sending and want the transport to slot into Messenger cleanly.

Look elsewhere when:

• You need Mailjet's marketing/contact features (lists, segmentation, campaigns, statistics) — this is a sending transport, not a platform SDK.
• You need inbound event handling (bounces, complaints, opens) — plan on Mailjet webhooks or the official SDK separately.
• You're on Laravel and want zero-friction config — the native Mailgun/SES/Postmark/SMTP mailers are simpler; this adds a custom-transport step for no functional gain unless Mailjet is mandated commercially.
• You require SMTP-only connectivity (e.g., locked-down network that permits only SMTP egress) — the Symfony bridge is API-oriented; use Mailjet's SMTP credentials with the generic SMTP transport instead.
• You want a multi-provider failover router — that's a Mailer-level concern (transports + failover strategy), not something this package provides.
• Dependency budget is tight: it's one more package to keep version-aligned with Symfony Mailer.

How to Pitch It (Stakeholders)

For executives (30 seconds): We need to send transactional email reliably. Rather than hand-building an integration, we adopt a small, MIT-licensed adapter maintained alongside Symfony that connects our mailer to Mailjet's API. Cost is near zero in engineering time and licence; the strategic benefit is that email delivery stays a configurable vendor decision — if Mailjet's price or deliverability disappoints, we change a setting, not the codebase. Risk is low and contained: it's glue, not a platform commitment.

For engineering leadership: It's a thin, upstream-maintained Symfony Mailer transport — API-based (no SMTP relay), compatible with Messenger for queued sending, and easily replaced. The only real integration cost is Laravel: it requires registering a custom transport, so approve it only if Mailjet is already the commercial choice. Version alignment with Symfony Mailer should be pinned and monitored.

For product/ops: It unlocks the standard transactional suite — resets, receipts, notifications — with provider-side observability and tagging, and lets us defer or reverse the ESP decision without rework. Anything beyond sending (campaigns, contact management, bounce/complaint workflows) is explicit separate scope, so plan those as their own backlog items rather than assuming the bridge covers them.