henrikbjorn/stampie
Stampie is a PHP library for sending email through API-based providers such as Mailgun, Mandrill, Postmark, and SendGrid. It provides a consistent mailer and message API, making it easy to switch transactional email services without rewriting your sending code.
Architecture fit
Stampie is a provider-agnostic PHP abstraction over transactional email HTTP APIs (Mailgun, Postmark, SendGrid, Mandrill/SparkPost-era providers). Architecturally it is a thin adapter layer: a common Mailer interface with per-provider transports, decoupling application code from vendor SDKs. That fits Laravel/PHP services that want to swap providers without touching domain code — the same value proposition Symfony Mailer and Laravel's Mail transport system now offer natively. The key TPM question is not "does the abstraction fit?" (it does, conceptually) but "is a second, parallel email abstraction justified on top of Illuminate\Mail?" For most Laravel teams, the honest answer is no unless there is a specific multi-provider or failover requirement.
Integration feasibility
Mechanically straightforward: Composer install, configure a transport with API credentials, call send(). There is no framework coupling, so it can be dropped into a Laravel service class or bound into the container. Effort is low (hours to a day for a first integration), but it sits alongside, not inside, Laravel's mail pipeline — meaning you forfeit Blade mailables, queued mail, events, and the Mail::fake() testing ergonomics unless you write glue code and adapters yourself. Feasibility is high; strategic fit is the weaker dimension.
Technical risk The dominant risk is lifecycle maturity, not code quality. The metadata is a red flag set: unknown repository location, 32 stars, a 0.28 composite score, and an MIT license with no visible release cadence. A dependency this small and this quiet is almost certainly in low- or no-maintenance mode. Secondary risks: HTTP client version pinning (older Stampie lines depend on legacy Guzzle), provider API deprecations that an unmaintained transport map will not absorb (Mandrill in particular), limited test coverage visibility, and a small talent pool that has seen the library. Security exposure is moderate — it handles API keys and outbound PII — so an unpatched transitive dependency is a real, not theoretical, concern.
Key questions
Illuminate\Mail cannot (provider failover, per-tenant transport routing, vendor-neutral portability)?Stack fit
Laravel already ships a first-class mail system with queued mailables, events, and fakeable transports, plus Symfony Mailer underneath. Stampie's fit is best described as "adjacent." It fits well as an isolated outbound adapter behind a domain-level EmailSender interface — a hexagonal boundary — rather than as a replacement for the framework mailer. That keeps the option open to retire it later without touching calling code.
Migration path
Treat this as an experiment, not a commitment. Wrap Stampie behind an internal interface with two implementations: a Stampie adapter and an Illuminate\Mail adapter. Route a single low-risk notification stream (internal alerts) through Stampie first. If the experiment does not justify itself within a sprint, delete the adapter; the interface survives and the blast radius is one class.
Compatibility
Verify PHP version support, PSR-7/PSR-18 compatibility, and Guzzle constraints before committing — a legacy HTTP client pin can force a conflicting dependency resolution across the whole application. Check that each target provider's transport still matches the live API. Prefer a tagged release; pin the exact version and commit composer.lock.
Sequencing
composer why, CVE scan, license check on transitive packages.Illuminate\Mail adapter.Maintenance This is the decisive cost. An unmaintained dependency becomes our dependency: provider API drift, PHP upgrades, and security patches land on our team. Budget an explicit fork-and-own estimate (roughly a few days per year of baseline upkeep, spiking whenever a provider changes auth or endpoint semantics) and record it against the alternative of using the framework mailer at zero marginal cost.
Support No vendor support, small community, and limited Stack Overflow footprint. Incident response depends entirely on internal knowledge. That is acceptable for a peripheral notification path and unacceptable for revenue-critical transactional email (password resets, receipts, onboarding).
Scaling
Throughput is bound by the underlying provider's HTTP API, not by Stampie, so horizontal scale is fine if sends are queued. The real constraint is the absence of native Laravel queue integration — we must own retry, backoff, rate limiting, and idempotency ourselves, duplicating what Illuminate\Mail provides for free. Per-provider rate limits must also be modeled explicitly.
Failure modes Provider-side 4xx/5xx and throttling (429) surface as exceptions from the transport; without a wrapper we get no retry policy, no dead-letter path, and no circuit breaker. Credential rotation is manual configuration. Silent failure is the dangerous mode: if a send throws outside a queue worker, notifications can be dropped without an audit trail. Mitigate with a queued job, structured logging of provider message IDs, bounce/complaint webhook ingestion, and an alert on send-failure rate.
Ramp-up
Developer ramp-up is genuinely low — the API is small and the abstraction is easy to read. The organizational ramp-up is the risk: future maintainers must learn a niche library with no public documentation ecosystem, and knowledge concentrates in whoever integrated it. Require an ADR documenting why Stampie was chosen over Illuminate\Mail, plus a short internal runbook covering credential rotation, provider swap, and failure triage.
TPM recommendation: Approve only as a time-boxed spike behind an internal interface, gated on the dependency audit and a clear answer to "what does this give us that Illuminate\Mail cannot?" Default position for a Laravel codebase is to decline and use the framework mailer.
How can I help you explore Laravel packages today?