Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Laravel Mailjet Driver Laravel Package

thedoctor0/laravel-mailjet-driver

thedoctor0/laravel-mailjet-driver provides a Mailjet transport for Laravel's native mail system, letting you send email through Mailjet's API via the Mail facade. Configure credentials and use familiar Laravel mail workflows with minimal setup.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Transactional email delivery choice: this package is a drop-in Laravel mail transport for Mailjet, so it directly informs the "which ESP do we standardize on" decision. Mailjet becomes viable if you want an ESP with both email and SMS under one vendor/account and a maintained first-party-style Laravel driver.
  • Build vs buy for notifications: 2.1.0's Mailjet::sendEmail() and Mailjet::sendSms() mean you can ship transactional email and SMS from one SDK instead of hand-rolling API clients. That collapses two integrations (email transport plus SMS provider) into one dependency — a genuine scope reduction for notification-heavy features (OTP, alerts, order updates).
  • Feature/roadmap unblocking: SMS support unlocks product surfaces (2FA via SMS, delivery notifications, appointment reminders) that previously required a separate Twilio/Vonage integration. Evaluate whether those roadmap items can now be delivered against the existing Mailjet contract.
  • Multi-channel notification architecture: with Laravel's notification system plus this driver, a single Notifiable abstraction can route to mail and SMS. This affects how you model user contact preferences and channel fallbacks.
  • Platform upgrade planning: the Laravel 11–13 / PHP 8.2+ support window is a forcing function. If you're on Laravel 9–10 you stay on 1.x (unmaintained going forward), which is a roadmap risk to weigh against your upgrade timeline.
  • Vendor consolidation: fewer vendors to contract, audit, and integrate — relevant if procurement or security review bandwidth is a constraint.

When to Consider This Package

Adopt when:

  • You're already on Mailjet, or are evaluating it, and want native Mail transport rather than a webhook/HTTP shim.
  • You're on Laravel 11, 12, or 13 and PHP 8.2+ — 2.1.0's supported range. Anything older must pin 1.x.
  • You need SMS in addition to email and would rather use one vendor's API than add a second provider.
  • You want confidence in maintenance: 100% line coverage of src/ and a CI matrix across PHP 8.3–8.5 × Laravel 11–13 is a strong signal of ongoing stewardship.
  • You need Send API v3.1, and specifically the v3 payload fallback for legacy templates or migration paths.

Look elsewhere when:

  • You're locked to Laravel 9–10 or PHP < 8.2 in the near term — 2.1.0 won't install, and 1.x is now a dead-end branch with no feature work.
  • You need advanced deliverability tooling (dedicated IP management, sophisticated suppression/engagement analytics) beyond what the driver exposes — the driver is a transport, not a deliverability platform.
  • SMS is a core, high-volume product surface with needs like short codes, two-way conversational messaging, or number pooling — Mailjet SMS API v4 is comparatively narrow; a specialist SMS vendor may be the better call.
  • You require a vendor-agnostic transport abstraction (e.g., swapping ESPs per environment or region) — this package tightly couples you to Mailjet.
  • You need capabilities the driver doesn't surface (bulk/batch endpoints, advanced templating controls) and would end up calling the raw SDK anyway.

Note the upgrade trap: the Laravel 11–13 trim is a deliberate breaking change in a minor version. Pin 2.0.x if you cannot yet meet the platform floor, and treat 1.x as frozen.

How to Pitch It (Stakeholders)

For executives: Mailjet's Laravel integration just became materially more useful. Version 2.1.0 adds native SMS sending alongside email, letting one vendor and one SDK cover two of our notification channels — which reduces vendor count, contract overhead, and integration work. It ships with full test coverage of the source and a current PHP/Laravel compatibility matrix, so the maintenance risk is low. The trade-off: it only supports recent Laravel versions (11–13) and PHP 8.2+, so adoption is gated on our platform upgrade timeline.

For engineering: 2.1.0 exposes Mailjet::sendEmail() (Send API v3.1, with an opt-in v3 payload fallback) and Mailjet::sendSms() (SMS API v4) directly, on top of the existing mail transport. The dependency bumps to mailjet/mailjet-apiv3-php ^1.6, which brings public setAuthentication(), raw-data params, and PHP 8.4 fixes. Support is trimmed to Laravel 11–13 / PHP 8.2+; anything on 9–10 must stay on 1.x. Internally it now has 100% line coverage of src/ (528 lines, 184 tests) and a CI matrix spanning PHP 8.3–8.5 across Laravel 11–13.

The ask: confirm our Laravel/PHP floor, then pilot the SMS path against a non-critical notification before committing. If we're not yet on Laravel 11+, decide whether the 1.x branch is an acceptable interim or whether that pushes our upgrade forward.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
frankkessler/guzzle-oauth2-middleware
delatbabel/site-config
delatbabel/applog
eusonlito/laravel-gettext
henzeb/housepedia-intelligence-laravel
aliqsm/laravel-authkit
itsjustvita/laravel-wp-migrator
uslanozan/laravel-cache-contract
adilazhari/laravel-trace
ulsyairil/ai-local-guardrails
dzwallet/laravel-sdk
glc36/maxloop-kernel
ikhbarnuridev/filament-mega-menu
mydnic/volet-chatbot
enadstack/laravel-localization
mydnic/volet-feature-board-filament-plugin
wmde/email-address
refinery29/test-util
dees040/laravel-api-responses
teamzac/geocoder