Resend Laravel Laravel Package

Product Decisions This Supports

• Email provider selection (build vs. buy). This package lets a Laravel team treat transactional email as a vendor decision rather than an engineering project. Swapping MAIL_MAILER=resend and adding RESEND_API_KEY is the whole integration, so the PM decision is "which ESP do we pay for and trust with deliverability," not "how many sprints does it take to build mail infrastructure."
• Transactional vs. marketing email split. The package covers the transactional rail (password resets, receipts, invitations, digests) via Laravel's native mailer, and exposes the broader Resend API (contacts, domains, audiences, topics, broadcasts) through the Resend facade. That means one vendor can serve both rails, or transactional can ship now while marketing tooling stays a separate later decision.
• Roadmap scoping for lifecycle messaging. Because webhooks (email.*, contact.*, domain.*, topic.*) can be received through a bundled controller/middleware with signature verification, engagement-driven features (bounce suppression, unsubscribe handling, "your email was opened/clicked" triggers, deliverability alerting) are days of work rather than a quarter. This directly unblocks notification-preference and re-engagement roadmap items.
• Reliability and support-cost trade-offs. Tags, idempotency keys, attachments (including inline/ICS), and X-Resend-Email-ID on the SentMessage mean retry semantics and support triage ("did this receipt actually send, and can we dedupe it?") are addressable without custom plumbing.
• Migration sequencing. It's a Symfony Mailer transport under the hood, so moving off SES/Mailgun/Postmark is a config change per environment with a staged rollout (canary domain, percentage of traffic) rather than a rewrite.
• Vendor lock-in posture. MIT license, thin wrapper over resend/resend-php, standard Laravel mailer interface. Exit cost is low, which strengthens negotiating position on pricing and gives a defensible "we can leave in a week" answer when procurement asks.

When to Consider This Package

Adopt when:

• The stack is Laravel 10/11/12+ on PHP 8.1+ and you want transactional email handled through the framework's standard Mail/Mailable abstraction — no bespoke HTTP client, no custom queue integration.
• You are choosing or re-evaluating an ESP and want a low-commitment pilot: one config file, one env var, reversible.
• You need webhook-driven email state (delivery, bounce, complaint, suppression, contact/topic changes) and want signature verification already solved.
• You want a single vendor for transactional and lifecycle/broadcast email, with idempotency keys and tags for observability.
• Developer experience matters as a hiring/retention lever — modern API, clean facade, official SDK alignment.

Look elsewhere or proceed cautiously when:

• Ecosystem maturity is a gating criterion. ~129 GitHub stars and no listed dependents is a thin public signal. This is the official Resend organization repo, so the real risk isn't abandonment — it's a smaller third-party knowledge base, fewer Stack Overflow answers, and less battle-testing than symfony/mailer SES or Mailgun transports.
• You need features the wrapper doesn't provide. Inbound email parsing, advanced sending-side templating/versioning, A/B testing, or deep analytics belong to other tools or to direct API calls.
• You require enterprise procurement artifacts. Sub-processor lists, DPAs, SOC 2 scope, regional data residency, and HIPAA BAAs are vendor questions about Resend, not this package — confirm them before the package matters.
• You are on legacy PHP/Laravel. PHP 8.1+ and current Laravel majors only; older apps need the SES or Postmark transports.
• You need guaranteed long-term API stability at a pinned minor. The project shipped a long 0.x series with frequent resend-php version bumps before 1.0; pin versions and read changelogs (the 0.21.0 inline_content_id → content_id rename is a good example of a silently breaking change).
• You need deep multi-provider failover. One provider, one transport; failover logic is yours to build.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk swap of our email vendor. It's an MIT-licensed, official integration maintained by Resend, installed with a single Composer command and configured with one environment variable — no new services, no migration project. It lets us consolidate transactional and lifecycle email under one vendor whose pricing and developer experience are competitive, and because it uses Laravel's standard mail interface, we can reverse the decision in days if pricing or deliverability disappoints. The measurable upside is faster shipping of notification and lifecycle features (webhook handling is already built) and fewer engineering hours spent on mail plumbing.

To engineering: It's a Symfony Mailer transport plus a Resend facade, so Mail/Mailable, queues, and existing mail templates keep working unchanged. We get signature-verified webhooks out of the box, attachments including inline and ICS, tags, and idempotency keys for safe retries — with the send ID surfaced on the sent message for tracing. The caveats are ours to manage: pin resend/resend-laravel and resend/resend-php, watch changelogs for breaking renames, keep provider-specific logic behind a thin internal interface so swapping to SES or Postmark remains a config change, and note the public ecosystem is small — we'll be reading source rather than blog posts when something breaks. Recommend a pilot on one non-critical mail flow for two weeks, then full cutover.