Weave Code
Mailjet Swiftmailer Laravel Package
mailjet/mailjet-swiftmailer
mailjet/mailjet-swiftmailer adds a Mailjet transport to Swift Mailer, letting PHP apps send transactional and bulk email through Mailjet's API. Existing Swift Mailer workflows keep building messages while Mailjet handles delivery, tracking, and scaling.
A SwiftMailer transport implementation for Mailjet
Frequently asked questions about Mailjet Swiftmailer
- Does mailjet/mailjet-swiftmailer work with Laravel 9, 10, or 11?
- No. Laravel 9 replaced SwiftMailer with Symfony Mailer, so there is no SwiftMailer transport pipeline for this package to plug into, and it does not implement Symfony\Component\Mailer\Transport\TransportInterface. It only fits Laravel 8.x and earlier via a custom Mail::extend registration, and Laravel 8 itself left security support in January 2023. For any Laravel 9+ application use Mailjet SMTP or a Symfony Mailer transport instead.
- How do I install and configure mailjet/mailjet-swiftmailer?
- Run composer require mailjet/mailjet-swiftmailer, which pulls in mailjet/mailjet-apiv3-php as its API dependency. The package does not ship a Laravel auto-discovery service provider, so you register the transport yourself in a service provider by calling Mail::extend and wrapping a Mailjet\Client in Mailjet\Transport\MailjetTransport. Store the API key and secret in config/services.php backed by environment variables, then set the mailer driver in config/mail.php. Keep the wiring in app/Support/Mail so it stays testable and swappable.
- What should I use instead of this package for sending Mailjet email from Laravel 9 or later?
- Start with the config-only SMTP route: set MAIL_MAILER=smtp, host smtp.mailjet.com, port 587 with TLS, and use your Mailjet API key as the username and secret as the password. Your existing mailables, notifications, and Markdown templates work unchanged, which covers roughly 95% of use cases with zero third-party code. If your host blocks outbound SMTP ports, build a custom Symfony Mailer transport around symfony/mailjet-mailer or the v3 PHP SDK behind TransportInterface and register it with Mail::extend using a DSN in config/mail.php.
- Is mailjet/mailjet-swiftmailer still maintained?
- No. The last release was June 2019, it has roughly 25 stars and zero dependents, and it has received no dependency updates in years. SwiftMailer itself reached end of life in November 2021 and gets no security patches. Treat the package as unmaintained and assume you own the fork plus any PHP compatibility fixes if you adopt it.
- Does mailjet/mailjet-swiftmailer support PHP 8.1, 8.2, or 8.3?
- There is no compatibility guarantee because nothing has been released since 2019. SwiftMailer internals emit deprecation notices on modern PHP versions, and the package has no test matrix covering PHP 8.x. If you must run it on a legacy Laravel 8 app with PHP 8, budget time to patch or pin dependencies yourself.
- How do I register the Mailjet transport in a Laravel 8 application?
- In a service provider's boot method, call Mail::extend('mailjet', ...) and return a MailjetTransport instance constructed with a Mailjet\Client holding your API key and secret. Then set 'driver' => 'mailjet' on the mailer entry in config/mail.php. Add credentials to config/services.php and your .env file, and place the transport class under app/Support/Mail so you can unit test it and swap it later.
- Can this package handle bounces, complaints, or per-message event tracking?
- No. It is a send-only transport: it posts messages to Mailjet's v3 send endpoint and returns the API response. Bounce and complaint webhooks, open and click events, and per-message tracking all require a separate integration with Mailjet's event API and your own webhook endpoint. Plan that work as its own task if you need deliverability signals.
- How does it handle queued mail and high-volume sending?
- Laravel's queueing happens at the Mailable and Mailer layer, so queued mail still works on Laravel 8 with this transport, but each send is a synchronous HTTPS call to Mailjet. Throughput per worker is therefore bounded by Mailjet's API rate limits plus network latency, and there is no batching. For peak volume, always queue, consider multiple workers, and compare against Mailjet SMTP, which pipelines more efficiently.
- How do I test an app that uses the Mailjet transport?
- Use Mail::fake() in application tests so the transport is never invoked and you assert against Mail::assertSent. For transport-level tests, inject a mocked Mailjet\Client or HTTP client and assert the payload and endpoint being called. Keeping the transport behind an interface in app/Support/Mail makes it easy to fake and to swap for SMTP or a Symfony Mailer transport later.
- Should I fork or vendor mailjet/mailjet-swiftmailer for production?
- It is MIT licensed and essentially one transport class, so forking is trivial technically. But a fork only makes sense on a Laravel 8 or earlier app with a committed, near-term framework upgrade, because you inherit all PHP minor-version patching. For Laravel 9+ the fork is pointless since SwiftMailer is no longer present, so use Mailjet SMTP or a Symfony Mailer transport instead.
Weaver
How can I help you explore Laravel packages today?