Laravel Mailjet Driver Laravel Package

Technical Evaluation

Architecture fit — The package occupies a well-defined seam: it is a mail transport adapter registered through Laravel's mail manager, configured via config/services.php + config/mail.php, and swappable by config alone. Blast radius is limited to outbound email, and the framework boundary is thin. That is the right shape for a third-party dependency.

The concern in 2.1.0 is that it opens a second, parallel integration surface. Mailjet::sendEmail() and Mailjet::sendSms() are static calls that bypass Illuminate\Mail\Mailer entirely — no Mailable, no mail events, no Mail::fake(), no queue integration, no log/array driver fallback in local and test environments. TPM framing: treat "mail transport" and "Send/SMS API facade" as two separate integrations with two separate testing and observability stories, not one package with a convenience method.

Integration feasibility — High. Composer-installable, package auto-discovery, no infrastructure prerequisites beyond an existing Mailjet account. The gating constraints are version, not effort: Laravel 11–13 and PHP 8.2+ only.

Technical risk

• Support floor is asserted but untested. Stated range is PHP 8.2+, while the CI matrix runs PHP 8.3–8.5. The minimum supported version — typically the one in older-but-not-yet-EOL estates — has no CI signal. Ask whether 8.2 is genuinely supported or merely declared.
• Laravel 13 in the matrix implies this release is tracking a forward-looking framework major. Verify our exact Laravel minor is covered and that routine patch upgrades don't silently fall outside the tested set.
• 1.x is now a maintenance branch for Laravel 9–10, with no stated EOL or security-fix policy. Any app still on L10 is now on an implicitly unsupported path — a framework-upgrade driver, not a package decision.
• SDK bump to mailjet-apiv3-php ^1.6 changes the authentication surface (setAuthentication() made public) and raw-data parameter handling. Credential-handling changes are the highest-consequence class of change here: misconfiguration tends to fail opaquely.
• Two payload shapes. Send API v3.1 by default with an opt-in v3 fallback. If different apps set the fallback flag inconsistently, we get divergent behavior for identical code — a debugging trap.
• No contract tests. 100% line coverage of src/ across 184 tests is a strong regression signal for logic, but it says nothing about the live Mailjet HTTP contract, which is where failures actually originate. Coverage is a weak proxy; the CI matrix is the better evidence.
• Bus factor. Single-maintainer wrapper around an official SDK. Acceptable for a transport adapter; less acceptable if we start routing revenue-critical SMS through it.

Key questions for the maintainer / internal owners

1. Is PHP 8.2 genuinely supported, or is the floor untested and aspirational?
2. What is the support and security-fix commitment for the 1.x branch?
3. Does the Send API v3.1 default change the payload on the existing transport path, or only on the new sendEmail() method?
4. What are the retry and idempotency semantics on sendEmail() for partial batch failures?
5. Who owns the Mailjet account, subuser structure, and API key rotation?
6. Is SMS genuinely in scope, or is it an unused capability we should explicitly forbid?

Integration Approach

Stack fit — Drop-in for any Laravel 11–13 service currently sending through Mailjet SMTP or the API directly; it replaces relay configuration with an API transport and yields structured API responses rather than SMTP status codes. SMS v4 is additive and architecturally independent — it should be evaluated on its own merits, not inherited from the mail decision.

Migration path — There is no 1.x → 2.x migration for L9/L10 apps; the framework upgrade is the prerequisite. For apps already on 2.0.x, 2.1.0 is minor and additive with no announced deprecations: pin ^2.1 rather than ^2.0 so the SDK fixes land, and expect no code changes to existing mail sending.

Compatibility checks before merge

• Composer conflict scan: anything else pinning mailjet/mailjet-apiv3-php at ^1.0–^1.5 will either block the upgrade or resolve to a version that breaks the driver.
• Confirm symfony/mailer constraints in our lockfile are satisfied by the Laravel 11–13 range.
• Verify the transport path is unaffected by the v3.1 default before assuming a no-op upgrade.

Sequencing

1. Spike (non-prod): install 2.1.0 in one service, send one message through Mailer and one through Mailjet::sendEmail(). Compare logs, error surfaces, and test ergonomics. This single step resolves most open risk.
2. Set a facade policy before rollout, not after. Recommendation: Mailer for all user-facing transactional mail; the static facade only where we need raw Send API capabilities that Mailable cannot express. Without this, teams will adopt whichever is shorter to write.
3. Gate SMS separately. If in scope, it needs its own cost, consent, and template-governance review; product teams should not call sendSms() directly.
4. Migrate transport per service behind config, keeping the prior SMTP settings available for one release cycle as rollback.
5. Evaluate the SDK bump independently for any service already using mailjet-apiv3-php directly — that is a different upgrade with different risk.

Operational Impact

Maintenance — Low steady-state toil while we sit on the supported matrix, but the "last three Laravel majors" policy converts every Laravel major into a package major and a potential forced app upgrade. Treat this dependency as part of the framework upgrade cycle in planning, not as a passive library.

Support — Single maintainer, no commercial backing. File upstream rather than fork. Because outbound mail is usually business-critical, keep a lightweight fork-feasibility note on file. The 1.x branch for L9/L10 has no stated sunset, which is unpriced risk for anyone still there.

Scaling — Throughput is bounded by the Mailjet plan's Send API rate limits and by Laravel queue worker concurrency, not by this package — no horizontal-scaling concern. The real scaling mistake is calling Mailjet::sendEmail() synchronously in a request path, which couples user latency to a third-party API and removes queue-based retry. Mandate queueing for anything on the facade.

Failure modes

• Credential/auth misconfiguration — worst case via the facade, where no mail events fire and failures surface as generic exceptions. Instrument explicitly.
• Payload-shape divergence — inconsistent v3/v3.1 fallback flags across services produce different behavior from identical code.
• Partial batch failures — retry and idempotency semantics are not described in the release notes; must be established empirically before batching.
• Deliverability feedback gap — bounces, complaints, and suppression handling live in Mailjet and are not addressed by this package; webhook ingestion is a separate build.
• Deploy-time resolution failure — a transitive SDK conflict breaks the build, not runtime; catch it in CI.
• Supplier discontinuation — mitigated by the fact that core mail flows through Laravel's own transport interface, so reverting to SMTP or another driver is a config change. Preserve that property by keeping the native path primary.
• SMS cost/consent — no budget cap, consent tracking, or receipt handling exists in the package; these are ours to build or to avoid needing.

Ramp-up — Roughly half a day for a Laravel developer to configure the transport and verify delivery. The facade and SMS add about a day once error handling and test fakes are accounted for. Required runbook additions: key rotation procedure, rate-limit alerting, bounce/complaint handling owner, and (if SMS ships) a spend cap. TPM-owned decisions: version pin policy (^2.1), a CI smoke test that actually sends and asserts, and a named owner for the Mailjet account.