All My Sms Laravel Package

Product Decisions This Supports

• De-risking SMS as a channel before committing to it. Use this package as a time-boxed spike (1–3 developer-days, most of it non-code) to answer one product question: does transactional SMS — OTP, order status, appointment reminders, payment dunning — move the retention/conversion metric we care about? Because it plugs into Laravel's native Notification/Notifiable system, the experiment costs a config file and one channel class, not a platform migration.
• Decoupling the integration decision from the carrier decision. Adopting this package quietly means adopting AllMySMS (a French gateway) for pricing, sender-ID registration, EU/France compliance, invoicing, and deliverability. The package is evidence that the integration is cheap. It is not evidence that the carrier is the right commercial partner for your markets. Keep those two decisions on separate agendas; conflating them is how teams end up locked into a vendor because of a 150-line driver.
• Build vs. buy on the driver layer. The honest comparison is "vendor and pin a ~150-line MIT channel" versus "write and test our own small HTTP adapter" at roughly 1–2 engineer-days. For a team already using Laravel Notifications, this is a spike-level call a tech lead can make, not a committee-level procurement.
• Roadmap sequencing for multi-channel notifications. SMS stays a swappable leaf on the notification tree. Email, push, and in-app can be layered later, and the provider can be replaced without touching domain code — provided engineering wraps the vendor channel behind an internal seam rather than referencing AllMySmsChannel directly in notification classes.
• Unblocking (or not blocking) a Laravel upgrade. v1.4.0 (June 2025) added Laravel 12 support, so this dependency no longer sits on the upgrade critical path. Note it is a compatibility-only release — no delivery receipts, inbound handling, retries, or improved error semantics came with it.
• EU/France market entry. For French users, a domestic carrier can simplify sender-ID registration, invoicing, and compliance conversations. This is a go-to-market consideration that US-centric provider comparisons routinely miss.
• Explicitly out of scope — plan headcount accordingly: inbound SMS, two-way conversations, MMS, multi-provider failover, delivery-webhook state machines, per-message cost analytics, and enterprise support/SLA. If the roadmap needs any of these, treat this package as a starting point at best and budget the additional engineering now, not later.

When to Consider This Package

Adopt when most of the following hold:

• The stack is Laravel and already uses Notifications for at least one channel. Adoption then reduces to a channel class, credentials, and env config.
• An AllMySMS account exists or is under active commercial evaluation. The integration is worthless without the commercial relationship; the package does not create one.
• Volume is low to moderate and traffic is one-way transactional — alerts, OTP, reminders, status updates — not marketing broadcast. There is no evidence of rate-limit handling in the package, so burst or bulk sending needs explicit throttling in queued jobs.
• You are prepared to own the code. One star, zero dependents, effectively a single maintainer, and reactive framework support (v1.4.0 was a compatibility-only PR). Mitigations are cheap but mandatory: a thin internal seam, a pinned ^1.4 constraint, and willingness to vendor under MIT.
• Failure semantics can be verified before you trust it. The highest-value day-one check is whether the channel throws on non-2xx responses and on error payloads hidden inside a 200 body. Many gateways return 200 OK with an error status in the JSON. If the package swallows that, queued jobs report success while OTPs silently vanish — the worst possible failure mode for a security-adjacent flow, and a one-line fix in a vendored copy.
• Sender-ID registration and country deliverability are budgeted as product work, not code work. Expect most of the spike to go to account provisioning, sender-ID registration (France/EU has rules; unregistered IDs get rejected or rewritten), and measuring real delivery rates against a capped SMS budget.

Look elsewhere, or plan supplementary engineering, when the roadmap requires: delivery receipts or a DLR state machine, inbound/two-way messaging, MMS, multi-provider failover, rate-limit handling, per-message cost analytics, or any form of vendor SLA. Also look elsewhere if the org cannot accept a single-maintainer dependency or cannot spare the engineering time to wrap and vendor it. And if cost-per-message or deliverability in non-French markets is the deciding factor, evaluate carriers first and treat the driver as replaceable.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can validate whether transactional SMS is worth investing in for roughly 1–3 developer-days and a capped SMS budget, using an existing MIT-licensed Laravel integration rather than a new vendor platform. It lets us test OTP, order updates, and reminders inside our current notification system, and it doesn't lock our code to a carrier — the driver is ~150 lines and replaceable. The trade-off is that it's a one-star, single-maintainer open-source package with no delivery receipts, inbound messaging, failover, or support SLA, so it's appropriate for a scoped experiment and early production on low-volume transactional traffic, not for a revenue-critical or two-way messaging roadmap without added engineering.

To engineering (the ask): Spend the spike on the things that actually determine success — carrier account setup, sender-ID registration, and confirming delivery in our target countries — not on PHP. Three conditions before this ships to anything security-adjacent (OTP):

1. Read AllMySmsChannel.php and confirm it throws on non-2xx and on error payloads inside a 200 body. If it doesn't, we vendor the class and fix it.
2. Wrap it behind an internal SmsChannel / AllMySmsMessage subclass. Notifications reference our seam, not the vendor channel, so a provider swap is a one-file change and composer update is never a merge conflict.
3. Pin ^1.4 and expect a lag window at every future Laravel major. v1.4.0 was compatibility-only; that's the maintenance pattern. MIT makes forking legal and cheap — it does not make it free.

Also: send E.164 only, normalise phone numbers on the way in, guard via() on verified numbers so we don't pay to text unverified or malformed ones, keep message bodies ASCII-only (one accented character drops GSM-7 from 160 to 70 chars per segment and silently doubles the bill), never log message bodies or phone numbers, and run config:clear after any credential change — a stale cached config here shows up as a swallowed API-key error in production.

What I need decided, and by whom: (a) Product/marketing — approve the capped SMS budget and the success metric for the spike; (b) Procurement/legal — confirm AllMySMS is acceptable commercially for our target markets before engineering invests; (c) Engineering — accept ownership of a single-maintainer dependency with a seam and a pin. If (b) is unresolved, run the spike against a staging account only and do not put OTP on it.