Laravel Mailcoach Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for email infrastructure. This SDK only makes sense if the answer to "buy" is Mailcoach (self-hosted v6+ or Mailcoach Cloud). It lets the team keep deliverability, unsubscribe compliance, and list management in a maintained product while driving it from our own Laravel app — rather than building sending infrastructure or bolting a generic ESP onto the product.
• Feature scoping on subscriber lifecycle. The SDK exposes createSubscriber, subscriber() lookups by email or UUID, confirm(), unsubscribe(), delete(), and attribute/tag updates. That's enough to decide whether signup, preference center, and list-hygiene features can ship as thin app-layer workflows instead of custom Mailcoach development.
• "Content in the app, sending in Mailcoach" roadmap bets. createCampaign() with templates and fields, plus sendTest() and send(), means campaigns can be generated from app data (CMS entries, product announcements, digests) and staged for human review before send. This is the single strongest product pattern the package enables: draft-and-approve pipelines owned by the product team, not the marketing team's inbox.
• Automation and integration use cases. Programmatic list creation, filtered subscriber reads (filter[email]=gmail.com) and full pagination traversal via next() make segment export, migration between providers, and lightweight sync jobs feasible without an internal API client. Reasonable candidates: onboarding sequences, waitlist→newsletter promotion, per-tenant lists.
• Roadmap constraint to flag early: this is a write-and-read client, not an event source. The README documents no webhooks, retries, rate-limit handling, or queueing. Any decision that depends on reacting to bounces, complaints, or opens — e.g., "auto-suppress hard bounces in our CRM" — cannot be justified on this package alone; it needs a separate ingestion path. Treat this as a scoping input, not a defect.
• Vendor dependency register. Adoption commits us to the Mailcoach API surface. Because the wrapper is thin (facade + resource objects with save()/delete()), exit cost is low: calls map closely to HTTP, so a swap is a bounded refactor rather than a rewrite. That materially lowers the "what if Mailcoach changes pricing" risk in the buy decision.

When to Consider This Package

Adopt when all of these hold:

• We are already on Mailcoach, or Mailcoach is the leading candidate in an active ESP evaluation, and we have API token + endpoint from the settings screen.
• The application is Laravel 12 or 13 (1.5.0 dropped support below 12) — this is a hard gate, and older Laravel apps need the earlier pinned release.
• We need server-side list/subscriber/campaign management in PHP and would otherwise hand-roll an HTTP client. The pagination ergonomics (next(), total(), currentPage(), previous()) alone justify the dependency for anything reading subscriber data at scale.
• The work is internal tooling, back-office automation, or a draft-generation pipeline — not a customer-facing real-time feature.

Look elsewhere or plan around it when:

• We are not on Mailcoach. This is not an abstraction over ESPs; it is a Mailcoach-shaped client. Choosing it is choosing Mailcoach.
• We need transactional/triggered email with latency guarantees. Campaigns and sendTest() are batch-shaped; there is no evidence of per-message primitives here. Evaluate Mailcoach's transactional offering or a dedicated provider separately.
• We need event-driven behavior (bounces, complaints, clicks, unsubscribes propagating back). Budget for webhook ingestion and idempotency as separate work.
• The consuming service is not Laravel/PHP, or we want a language-neutral contract. Use Mailcoach's HTTP API directly and treat this as a reference implementation.
• We need fine-grained control over retries, backoff, and rate limiting under load. The SDK gives no documented knobs; verify before committing to high-volume batch jobs, and assume we wrap calls in our own queued jobs.
• Maturity caveat for the risk log: 42 stars and zero dependents means near-zero external validation — no independent bug-finding, no ecosystem of usage patterns to copy. It is Spatie-maintained, tested, changelogged, and MIT-licensed, which is a real quality floor, but adoption should rest on the maintainer's track record and the thinness of the wrapper, not on community traction. Keep it a convenience layer; do not let it become load-bearing architecture.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) integration library that lets our Laravel app drive Mailcoach — creating lists, syncing subscribers, and generating campaigns — without building any email infrastructure ourselves. It replaces what would be roughly one to two weeks of custom API plumbing with a composer require and a config file. It does not lock us in: the library is a thin wrapper over documented endpoints, so if we ever leave Mailcoach, replacing it is a contained refactor rather than a platform migration. The strategic decision to weigh is the ESP choice, not the SDK; this package simply makes the Mailcoach option cheaper to execute.

To engineering: Low-risk, low-ceremony dependency. Spatie-maintained, MIT, active releases, CI and changelog in place, and the API is a facade plus resource objects with save()/delete() and iterable paginated results. Costs: it pins Laravel 12–13, it only covers what the Mailcoach API covers (no webhooks, retries, or rate-limit handling documented — we build those if we need them), and it has essentially no external adoption, so we are early users and should expect to read the source rather than find answers online. Recommended posture: adopt for internal tooling and campaign-draft pipelines now; wrap all calls in our own queued jobs and a thin internal service class so the SDK stays swappable and testable.