Swiftmailer Send Grid Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for transactional email delivery: this package is a thin transport adapter, not an email platform. It answers "should we write our own SendGrid transport for a Swiftmailer-based app?" — and the answer is almost always no, because the equivalent is a config line in any modern framework.
• Platform lifecycle / roadmap: the fact that this is a candidate at all is a signal your stack is on Swiftmailer, which reached end-of-life in late 2021. The decision this package really informs is "when do we schedule the migration to symfony/mailer?" — not "which SendGrid package do we install?"
• Vendor standardization: supports the choice of SendGrid as an email vendor (API key auth, web API vs. SMTP relay, event webhooks), but contributes nothing to that decision beyond proving a transport is technically possible.
• Legacy maintenance triage: for an inherited Symfony 2.8/3.x app, it is a reference implementation of the Swift_Transport interface and bundle wiring. Reading ~100 lines of source is cheaper than reverse-engineering Swiftmailer's transport contract — but fork it, don't depend on it.
• Supply-chain risk register: 9 stars, 0 dependents, last release 2018-07-03. Adopting it creates a dependency with no upstream maintainer, no security response path, and no compatibility testing against current SendGrid APIs. That is a decision in itself, and the wrong one.

When to Consider This Package

Consider it only if all of the following are true:

• You operate a Symfony 2.8/3.x application already pinned to Swiftmailer.
• There is no appetite or budget this quarter to touch mail configuration.
• You need a stopgap SendGrid transport and are prepared to vendor/fork the code into your own repository.
• You have verified which SendGrid API version it targets — SendGrid's v2 Web API is retired, so confirm it speaks v3 before assuming it works at all.

Look elsewhere if any of the following apply (this covers nearly every case):

• Laravel 9+: use the framework's own Mail facade — symfony/mailer (which Laravel wraps) plus symfony/sendgrid-mailer, or plain SMTP with an API key. First-party, maintained, one config entry. Do not introduce a Symfony bundle into a Laravel app.
• Symfony 5.3+/6/7: use symfony/sendgrid-mailer — the officially maintained bridge, same vendor, same API.
• Framework-agnostic PHP: use the official sendgrid/sendgrid-php SDK.
• You want deliverability features (suppression lists, event webhooks, templates, inbound parse): a transport adapter gives you none of that; choose a vendor with a maintained first-party integration (Postmark, Mailgun, Resend, SES) and budget for the integration properly.
• You need security patching or vendor support: no upstream maintainer exists here.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. gulaandrij/swiftmailer-send-grid-bundle is a Swiftmailer transport and Symfony bundle for SendGrid, last released in July 2018, with 9 stars and zero dependent packages. It sits on a framework component (Swiftmailer) that is end-of-life, and it carries no maintainer, no security response path, and no evidence of testing against SendGrid's current v3 API.

For engineering: the capability we actually need — "send mail through SendGrid" — is already solved by maintained, first-party code. In Symfony 5.3+ it is symfony/sendgrid-mailer. In Laravel 9+ it is the built-in Mail facade with the Symfony SendGrid bridge or an SMTP transport using an API key. Both are a configuration change, not an integration project. If a legacy Swiftmailer app genuinely blocks us, fork the transport into our own repo and own those ~100 lines — do not take a dependency on an abandoned package.

Cost and risk: the maintained path is roughly a day or two of configuration and testing, and it removes a permanent maintenance liability. The abandoned path is a quick install followed by unbounded risk: an API version that may already be sunset, no patch if SendGrid changes behavior, and a dependency our security tooling will flag indefinitely.

Ask: approve the small migration effort toward the framework-native SendGrid transport, and formally exclude this package from our dependency policy.