Mailjet Bundle Laravel Package

Technical Evaluation

Architecture fit. Poor as-shipped, workable only after reframing. mailjet/mailjet-bundle is a Symfony bundle: its entire contribution is DI service definitions, a configuration tree, and autowiring aliases registered into Symfony's container. Laravel does not consume bundles — it consumes Symfony components via its own container and package discovery. Nothing in this package's value proposition (bundle registration, YAML config tree, mailjet.apiv3 / mailjet.transport service IDs) transfers to a Laravel application. The reusable asset is the wrapped mailjet/mailjet-apiv3-php SDK, not the bundle.

Integration feasibility. Treat it as a reference implementation, not a dependency. The realistic TPM-approved path: read DependencyInjection/Configuration.php and Resources/config/services.xml — those two files are the entire contract — then build a thin Laravel service provider over the official SDK (client singleton binding, optional facade, optionally a symfony/mailer transport so Mail::to(...)->send(...) keeps working). Sizing: 1–3 engineer-days for the SDK wrapper plus tests; 3–5 days if a full transport with queue integration is required. Cheaper than fighting a foreign bundling model.

Technical risk — high, concentrated in staleness. Last release 2019-06-17 places it in the PHP 7.x / Symfony 3–4 era: expect tight php and symfony/* constraints, a Swiftmailer-era transport (Swiftmailer is EOL), and no PHP 8.2/8.3 or Symfony 6/7 support. composer require against a modern Laravel (illuminate/* 10/11) will very likely fail to resolve. Zero dependents and 33 stars mean no downstream validation, no issue triage, no security response. The Mailjet API v3 endpoints remain current, so the protocol risk is low — the wrapper risk is the whole risk.

Key questions for a timeboxed spike.

1. Does the bundle delegate to mailjet/mailjet-apiv3-php, or reimplement HTTP calls (and therefore hide auth/retry logic we'd have to rebuild)?
2. What are the exact composer.json constraints, and do they conflict with our Laravel and guzzlehttp/guzzle pins?
3. Is the transport Swiftmailer-based? If so it is unusable on Laravel 9+ and must be discarded outright.
4. Does it cover webhook signature verification, or outbound send only?
5. Are there pinned, unpatched transitive dependencies (Guzzle 6, old psr/*)?

Integration Approach

Stack fit — do not install the bundle. Recommended target architecture inside the Laravel app: mailjet/mailjet-apiv3-php as the sole Mailjet dependency; a MailjetServiceProvider binding a configured client singleton plus a facade; a Symfony\Component\Mailer\Transport\AbstractTransport subclass if Mailjet should sit behind Laravel's native Mail facade (preserving queueing, events, and existing call sites); config published into config/services.php / config/mail.php reading from env vars, consistent with the rest of our mail configuration.

Migration path. This is a build, not a migration. (1) Spike the SDK against a Mailjet sandbox account. (2) Wrap the client behind our own interface so the ESP stays swappable. (3) If needed, implement the transport behind the existing Mail facade so no call site changes. (4) Decommission any legacy SMTP/Swift path. No code is inherited from the bundle, so there is no cutover of a running system — only additive scope.

Compatibility. Pin the SDK to a Guzzle major that matches Laravel's; verify PHP 8.2/8.3 in CI; assert queue-driver compatibility. Record explicitly, in the decision log, that the bundle itself will not resolve against our stack — so no engineer burns a sprint attempting it. If a Mailjet package is genuinely wanted, the correct comparable is the maintained Laravel-specific wrapper (mailjet/laravel-mailjet), not this artifact.

Sequencing. Spike (0.5d) → go/no-go on Mailjet as ESP → SDK wrapper + tests (1–3d) → transport and queue integration if required (3–5d) → observability and failure-path tests (1–2d) → rollout behind a feature flag with shadow-send comparison against the current provider before cutover.

Operational Impact

Maintenance — we own it outright. Because we would not depend on the bundle, ownership of the wrapper sits with our team: a ~200-line adapter we control, versus an abandoned third-party bundle we cannot patch. The trade-off is that the package provides no long-term leverage; its score (3.4) and opportunity (23.31) accurately signal a low-upside artifact. Installed anyway, it would be unmaintained code in the dependency tree — an audit liability with no patch path.

Support. No upstream support, no active issue queue, no security advisories. Mailjet's own API documentation and SDK are the support surface. The TPM ask: designate an API-key/account owner and document the Mailjet plan tier (sending limits, sub-account strategy, IP reputation posture), since the bundle offers none of that.

Scaling. Constraints are Mailjet-side, not code-side: daily send quotas, per-request recipient caps (chunk batch sends), API rate limits with 429 backoff. The Laravel queue is the right lever — dispatch sends as queued jobs, use Mail::queue, keep the transport stateless. Do not put synchronous sends in request paths.

Failure modes to design for explicitly.

• Mailjet 5xx / timeout → bounded retry with exponential backoff and jitter; idempotency via our own message keys to prevent duplicate sends.
• 4xx (auth, invalid sender, suppressed recipient) → classify permanent, fail fast, alert; never retry.
• Partial batch failure → per-recipient error mapping rather than all-or-nothing.
• Webhook ingestion (bounce, spam, open/click) → verify signatures, ack 2xx fast, process async; otherwise Mailjet disables the endpoint.
• Silent degradation → send success rate and latency as first-class metrics with alerting on drop.
• Key rotation → secrets in a vault/env, never in committed config/.

Ramp-up. Low for the SDK-wrapper path: any engineer comfortable with the Mail facade and Guzzle can operate it in under a day. The bundle would increase ramp-up by introducing a foreign container/config idiom with no documentation and no community examples.

TPM recommendation. Do not adopt mailjet/mailjet-bundle. Use it only as a design reference for service wiring; build a thin Laravel adapter over mailjet/mailjet-apiv3-php. Low risk to trial, low risk to abandon, low strategic value — a Symfony-era artifact whose staleness, zero dependent base, and low opportunity score make it a net-negative dependency.