Mail Php Laravel Package

Product Decisions This Supports

• ESP selection for transactional email. Adopting this client is a de facto commitment to WiseData Mail as the delivery vendor for password resets, receipts, order confirmations, and notifications. That is a critical-path dependency, so the decision should be made on the vendor's SLA, deliverability, pricing, and support commitments — not on the existence of a convenient wrapper.
• Build vs. buy on the integration layer. The package is a thin HTTP client over the WiseData Mail REST API (contacts + transactional send). Reproducing it is roughly one to two days of engineering. "Buy" (adopt) only makes sense once the vendor is already chosen; otherwise this is commodity glue and you're better served by an official SDK for a vendor you've actually evaluated.
• Lifecycle messaging roadmap. The contacts API opens a path to syncing product users into a mailing list for onboarding sequences, re-engagement, and light segmentation — without standing up a CRM or CDP for a first iteration. That's a real scope-saving option for a small team.
• Notification architecture: transport abstraction. The key PM-level question is whether email transport is swappable. If yes, this package is one adapter behind an interface and the risk is contained. If no, you've coupled the product to an unproven single-vendor library, and every future provider change becomes a refactor.
• Data residency and LGPD posture. A Brazil-oriented vendor may be attractive for local data-handling requirements. The client doesn't solve compliance, but it shapes the vendor shortlist and the questions legal will ask.
• Scope cuts. A hosted contacts-and-send API lets a small team ship lifecycle email without building list management, suppression handling, or preference centers in-house.

When to Consider This Package

Adopt when:

• WiseData Mail is already the selected (or contractually required) ESP and the stack is PHP/Laravel.
• You need both contact management and transactional sending from one API and want to skip writing the client yourself.
• The integration is small and internal — not a core product surface — and you can absorb ongoing maintenance.

Look elsewhere or write your own when:

• There is no existing vendor commitment. Evaluate Postmark, SES, Mailgun, Resend, or Laravel's native mailers first; they have maintained official SDKs and, critically, existing Laravel transports.
• You want Laravel-native ergonomics (Mail::to()->send(), queued mailables, events, failure handling). This is framework-agnostic PHP, so you will wrap it in a service provider and likely a custom Illuminate\Mail\Transport registered via Mail::extend. That wrapper is most of the work the package was meant to save.
• You need inbound email, webhooks, advanced templating, per-message event tracking, or deliverability analytics — confirm the vendor API covers these before assuming the client does.
• You require community support, security review, or long-term maintenance guarantees. Zero stars and zero dependents means no ecosystem safety net; treat it as vendor sample code you may end up forking.
• Sending is high-volume or compliance-sensitive: get the SLA, domain/IP warm-up plan, and bounce/complaint handling in writing.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed client for one email vendor's API. It's cheap to adopt and saves days, not months — it is not a strategic asset and should not anchor the vendor decision. The real decision is which provider carries our transactional mail and what happens when it fails. Recommend a short vendor evaluation (deliverability, SLA, pricing, LGPD posture) with this client treated as an implementation detail, plus a documented fallback route for auth-critical email. Package cost is near zero; the risk is lock-in and an unmaintained dependency, which costs roughly a sprint of rework if we swap later — contained by keeping it behind our own interface.

To engineering: Expect a thin, framework-agnostic HTTP wrapper — no Laravel service provider, facade, queue integration, retry policy, or typed DTOs out of the box. Plan to: (1) hide it behind our own mailer/transport interface; (2) register a Laravel mail transport so product code stays on Mail::; (3) add timeouts, retries, idempotency keys, and a secondary provider for password resets and receipts; (4) pin the version and assume we own the fork, because with 0 stars and 0 dependents, upstream support is us. Treat it as a starting point, not a dependency we can lean on.