Mailjet Swiftmailer Laravel Package

Technical Evaluation

Architecture fit — poor for current Laravel, acceptable only on legacy stacks. This package is a single-purpose SwiftMailer transport (Mailjet\Transport\MailjetTransport) that wraps Mailjet's API v3 PHP SDK (mailjet/mailjet-apiv3-php) to send mail over HTTPS instead of SMTP. Laravel 9 (Feb 2022) replaced SwiftMailer with Symfony Mailer, so the package is architecturally incompatible with the framework's current mail pipeline (Symfony\Component\Mailer\Transport\TransportInterface). It is only a natural fit for Laravel ≤8.x via a custom transport registration in a service provider (Mail::extend / MailManager::extend). Laravel 8 left security support in January 2023, meaning the only architecture this package cleanly fits is itself out of support.

Integration feasibility — moderate effort, low value. The library is small (essentially one transport class plus a composer dependency) and MIT-licensed, so vendoring or forking is trivial. Two integration options exist:

Given that Mailjet's SMTP endpoint provides the same delivery path with zero third-party code, the package's only genuine advantage is API-based sending (useful when outbound SMTP ports are blocked or when you want structured API error payloads).

Technical risk — high, and mostly unrelated to Mailjet. The dominant risk is the abandoned SwiftMailer foundation (EOL Nov 2021, no security patches), compounded by a package last released 2019-06-13, 25 stars, and 0 dependents — meaning effectively no field-proven usage and no community regression signal. Concretely: no PHP 8.1/8.2/8.3 compatibility guarantee, deprecation noise from SwiftMailer internals, no dependency updates in five years, and no maintainer response path if the Mailjet API contract shifts. The Mailjet API v3 itself is stable, so the transport logic is unlikely to break from Mailjet's side — the breakage vector is PHP/framework upgrades behind it.

Key questions for the vendor/team:

• Which Laravel version is actually in production, and is there a framework upgrade committed within 12 months? (If yes, this package is a dead end by definition.)
• Why API-send rather than Mailjet SMTP — is there a documented egress/port-25 restriction?
• Who owns the fork if we adopt it, and what is the patch SLA for PHP minor releases?
• Do we need bounce/complaint webhooks and per-message event tracking? This transport provides none; that pushes work to a separate v3 event API integration.
• What is the sending volume profile (messages/sec peak), and does the transport's one-HTTP-call-per-message model plus Mailjet rate limits hold?
• Are SPF/DKIM/DMARC and the sending domain already validated in Mailjet?

Integration Approach

Stack fit. Target stack assumption: PHP 8.x, Laravel 10/11, queued mail. On that stack this package does not fit at all — SwiftMailer is not present. Recommendation: do not adopt for any Laravel ≥9 application. For legacy Laravel 7/8 applications, it is a viable but time-boxed bridge.

Migration path (recommended, in priority order):

1. Config-only baseline (all versions): point config/mail.php at Mailjet SMTP with API key/secret credentials, MAIL_MAILER=smtp, TLS on 587, and reuse existing Laravel mailables, notifications, and Markdown templates unchanged. This satisfies ~95% of use cases with zero new dependencies.
2. Laravel 9+ API-send path: if HTTPS-only egress is required, register a custom transport resolving Mailjet's v3 send endpoint (via symfony/mailjet-mailer or mailjet/mailjet-apiv3-php behind a TransportInterface implementation), wired through Mail::extend() with a DSN in config/mail.php. Keep it in app/Support/Mail/ so it is testable and swappable.
3. Legacy bridge: for Laravel ≤8 only, register this package's transport in a MailServiceProvider, constructor-injected with keys from config/services.php (never hardcoded), and pin the exact version in composer.json with a provide/replace note.

Compatibility. Verify PHP constraint versus the app's PHP version before anything else; the 2019 release predates PHP 8.1. Lock mailjet/mailjet-swiftmailer and its mailjet/mailjet-apiv3-php and swiftmailer/swiftmailer transitive versions, and add a Composer conflict guard so a future framework upgrade fails loudly rather than silently breaking mail.

Sequencing.

1. Inventory all mail paths (framework mailables, notifications, raw Mail::send, third-party packages that ship their own mailers).
2. Stand up Mailjet SMTP in staging; validate SPF/DKIM/DMARC and sender reputation on a subdomain.
3. Run a two-week soak with real traffic mirrored to staging; measure latency, bounce handling, and 4xx rates.
4. Only if API-send is mandated, build and test the custom transport behind a feature flag alongside SMTP.
5. Roll out per-mailer (transactional first, then marketing/bulk), with SMTP as an instant rollback target.

Operational Impact

Maintenance. The package is a permanent maintenance liability: no upstream fixes, and the transitive SwiftMailer dependency is EOL. Assume you own the code. Budget a fork in a private VCS with a CI matrix over supported PHP versions, plus a quarterly review triggered by PHP minor releases. If you choose the SMTP route instead, recurring maintenance drops to near zero — this asymmetry should drive the decision.

Support. No vendor support, no issue triage, 0 dependents means no community knowledge base. Mailjet support will not debug a third-party SwiftMailer transport. Internal support model must be "one named owner + runbook," and that owner must be able to read SwiftMailer internals.

Scaling. The transport issues one HTTPS API call per message, so throughput is bounded by Mailjet's per-endpoint rate limits and HTTP round-trip latency, not by your PHP workers. Synchronous sending is therefore not viable above low volume — mail must go through queues with concurrency tuned conservatively to avoid 429s. The transport does not implement retry/backoff, so burst behavior degrades into queue retries. Bulk campaigns should bypass this path entirely in favor of Mailjet's batch/campaign APIs.

Failure modes to instrument:

• Permanent 4xx (invalid sender, suppressed recipient, bad key) surfaces as a transport exception and can be retried by the queue as if transient — needs exception classification and non-retryable marking.
• Key rotation silently breaks sending until the first failure; alert on send-failure rate, not on queue depth alone.
• Credential leakage in exception messages/logs — audit failed_jobs payloads.
• Deliverability drift with no bounce/complaint feedback loop in the transport; requires a separate Mailjet event API consumer.
• Framework upgrade breaking mail on deploy with no compile-time signal — mitigated by the Composer conflict guard and a post-deploy transactional smoke test.

Ramp-up. Low technical ramp-up (one class, well-understood pattern) but high conceptual debt: engineers under ~30 will have no SwiftMailer familiarity, and the abstraction leaks legacy idioms into new code. Onboarding cost is better framed as "one more thing to learn that we intend to delete." Net recommendation: reject as a strategic dependency; use Mailjet SMTP for immediate need and a Symfony Mailer-based custom transport if API-send becomes a hard requirement.