Laravel Mailjet Sms Laravel Package

Product Decisions This Supports

• Feature decision: add SMS as a notification channel with minimal commitment. The package plugs Mailjet SMS into Laravel’s native notification system, so a PM can test SMS-based flows (OTP/2FA codes, order and shipping updates, appointment reminders, failed-payment dunning, internal ops alerts) using the same via() notification plumbing as email — no new architecture, no new SDK, no rework of the notification layer if the experiment is killed.
• Vendor consolidation (build vs. buy). If Mailjet is already the email provider, this is a "buy at the adapter layer" decision: one vendor account, one set of API credentials, one billing relationship, one DPA/GDPR contract to review. That's a procurement and compliance simplification, not just a technical one.
• Roadmap sequencing. Because the channel is an interchangeable adapter, SMS can be scoped as a thin slice on the roadmap (spike → internal dogfood → single flow like OTP → broader rollout) with a clear kill switch. Delivery economics and country coverage can be validated before committing to a multi-quarter messaging platform.
• Opportunity signal. The package is effectively unclaimed territory (near-zero adoption, no dependents, stale release) — which tells you the capability is underserved in the Laravel ecosystem, not that this specific artifact is a strategic bet. Treat it as a validation vehicle, not a foundation.
• Fork-or-reimplement decision. The surface area is small (a notification channel plus a thin HTTP client for Mailjet's SMS send endpoint). A PM should assume the realistic options are "use as-is," "vendor a fork," or "rebuild in ~1–2 engineering days" — and that the rebuild cost is low enough that maintenance risk is a scheduling question, not a blocker.

When to Consider This Package

Consider it when:

• Mailjet is already your email provider and you want SMS under the same contract, credentials, and vendor-risk review.
• You need SMS notifications quickly for a narrow, transactional use case (OTP, transactional alerts), at low-to-moderate volume.
• Your recipient countries are ones Mailjet actually covers well — verify this per market before committing; SMS coverage is regional, not global, and sender-ID rules vary by country.
• Your Laravel version is compatible (last release was February 2023, so validate constraints against your current framework version and PHP runtime before estimating).
• You accept forking or vendoring the package, and your team can own a small amount of glue code.

Look elsewhere when:

• You need global delivery, two-way/inbound SMS, delivery receipts, WhatsApp/RCS, or high-volume negotiated pricing — go to a dedicated CPaaS (Twilio, Vonage, Sinch, AWS SNS) or Laravel's first-party Vonage channel.
• You require a maintained dependency with a support path — 5 stars, 0 dependents, and a 2023 release are disqualifying for anything customer-critical without a fork.
• Your use case is compliance-sensitive (marketing SMS, consent capture, opt-out handling) and you need documented provider guarantees rather than a thin wrapper.
• You're on a newer Laravel major and can't absorb the upgrade work — budget for it or rebuild.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, reversible experiment to add SMS — starting with OTP and transactional alerts — without opening a new vendor relationship, since it rides on our existing Mailjet account. The engineering cost is small and the exit cost is roughly a day of work, because the SMS provider sits behind Laravel's standard notification interface and can be swapped without touching product code. The main caveat is that the open-source wrapper itself is a small, unmaintained project, so we'd plan to fork and own it rather than depend on it. Net: a cheap way to test whether SMS moves a metric (login completion, delivery-notification engagement, failed-payment recovery) before we commit to a dedicated messaging vendor.

To engineering: Treat it as an adapter, not a platform. Validate Laravel/PHP version constraints and Mailjet SMS API availability first, then wrap the channel behind our own interface or fork it so upgrades and provider swaps stay local. Confirm country coverage, per-message cost, and sender-ID requirements for our target markets, and define the fallback path (email or in-app) when SMS delivery fails. Success criteria, not just ship criteria: delivery rate, OTP completion rate, cost per successful message, and a documented swap path to a dedicated CPaaS if volume or coverage outgrows it.