Lettermint Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for transactional email: Lettermint ships a first-party Laravel mail transport, so sending can stay on Laravel's native Mail facade instead of an in-house SMTP/deliverability stack. The PM decision this supports is "don't own deliverability infrastructure" — the package is the integration cost, not a rewrite.
• Feature: delivery visibility and lifecycle messaging. The webhook events (outbound/inbound message events) map to Laravel events, so product surfaces like "email delivered / bounced / complained" status badges, resend flows, and suppression lists are event-listener work rather than polling jobs or a custom webhook receiver.
• Feature: email threading and conversation views — this is what 3.1.0 unlocks. Exposing message headers on outbound message events means Message-ID, In-Reply-To, and References can be persisted from the same event that already tells you a message was sent. That makes a threaded conversation/timeline UI feasible without a parallel store of send-time metadata or a second round-trip to the provider's API.
• Feature: custom header-driven routing and instrumentation. Teams that tag outbound mail with X- headers (tenant ID, campaign, workflow ID, A/B variant) can now read those back on the outbound event and use them as correlation keys for analytics and support tooling. This turns headers into a lightweight, low-ceremony event schema — a real alternative to adding a database column and a queue job just to correlate sends.
• Roadmap: EU data residency and GDPR posture. For products with EU customers or EU-resident data obligations, the vendor's EU positioning is a roadmap-relevant differentiator that can unblock a market or a procurement review; the Laravel package keeps that choice reversible behind the framework's mail abstraction.
• Roadmap: inbound email as a product input. Inbound message events support reply-by-email features (ticket comments, thread replies, notification acknowledgements), which is typically a quarter-sized roadmap item when built from scratch.
• Multi-tenant architecture: per-tenant sender domains/credentials become a configuration concern rather than a separate integration per tenant.

When to Consider This Package

Consider it when:

• The application is Laravel (or at least PHP) and already sends mail through the Mail facade — the migration is a config swap plus listener registrations, so the cost of trying it is measured in hours, not sprints.
• You need transactional email with delivery-event feedback (bounces, complaints, delivered), not campaign/marketing automation.
• Data residency (EU) or vendor-diversity is a stated requirement from security, legal, or enterprise procurement.
• You want inbound email as a product feature with a small integration surface.
• You're prepared to consume webhooks — meaning you have (or will build) a public endpoint, signature verification handling, queue-backed listeners, and idempotency. The package handles the Laravel ergonomics; it does not remove the operational work of receiving webhooks reliably.

Look elsewhere when:

• You need a visual template builder, journey/campaign automation, or list management — that's a marketing platform, not this.
• You're not on Laravel — use the underlying SDK directly and skip the framework wrapper.
• You require on-premise or self-hosted SMTP relays, or contractual SLAs and a long public uptime history that a younger vendor may not yet have. Mitigate lock-in by keeping sending behind Mail/a small interface so a swap to Postmark/SES remains a config change.
• Your volume profile demands committed-volume enterprise pricing and dedicated IP warm-up management — validate commercial terms before committing the roadmap.
• Header exposure is your primary reason to adopt — verify your specific headers survive the outbound event payload end-to-end in a staging environment before designing a feature around it.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-risk integration that lets us send transactional email through an EU-based provider using Laravel's built-in mail system — no new infrastructure, no migration project. It buys us delivery-event visibility and inbound email as product capabilities, and it reduces data-residency and compliance exposure for EU customers. The main risk is vendor maturity, which we contain by keeping the integration behind Laravel's standard mail abstraction so switching providers stays a configuration change rather than a rewrite. The 3.1.0 release adds outbound message headers to the event payload — a modest but useful addition that lets us build email threading and correlation on top of events we already receive, avoiding an extra data store.

For engineering (summary): A first-party Laravel transport plus Laravel events for outbound and inbound message webhooks. Register listeners, queue them, make them idempotent; the package handles the transport and event dispatch. 3.1.0 is additive and non-breaking: outbound message events now carry message headers, so Message-ID/References/In-Reply-To and any custom X- tags are available at send-time notification without an additional API call. Practical consequences: persist the headers on the event (they are the cheapest correlation key we have), and treat header contents as untrusted input when rendering. No action required if we don't consume headers yet — upgrade is a patch-level change from 3.0.0.

Asks: (1) Approve a timeboxed spike: one non-critical transactional flow on Lettermint behind the existing Mail abstraction, with a rollback config. (2) Confirm legal/security sign-off on data residency and DPA. (3) If approved, scope header persistence (threading + correlation) as a follow-on ticket rather than bundling it into the migration.