All My Sms Laravel Package

Technical Evaluation

What this actually is. A ~150-line Laravel notification channel that maps Laravel's Notification/Notifiable abstraction onto the AllMySMS HTTP API. It is an adapter, not a platform: no delivery receipts, no inbound/two-way, no MMS, no failover, no rate-limit handling, no per-message cost analytics. The evaluation should be framed as "do we adopt AllMySMS as a carrier, and is this adapter cheaper than writing our own?" — two separate decisions that this package quietly couples together.

Architecture fit.

• Slots in as a leaf on Laravel's existing channel tree alongside mail, database, and push. Domain code stays untouched because routing lives on the notifiable model (routeNotificationForAllMySms()), not in the message.
• Fits well if the team already uses Laravel Notifications for at least one other channel; adoption then reduces to a channel class, credentials, and env config.
• Does not force a domain model or an SMS service layer. That is both the appeal and the limitation — there is no abstraction for templates, opt-outs, or delivery state, so anything beyond fire-and-forget is ours to build.

Integration feasibility.

• Code cost is 1–3 developer-days by the package's own assessment, and almost none of that is PHP. The real work is account provisioning, sender-ID registration (France/EU rules; unregistered alphanumeric IDs get rejected or rewritten), and confirmable deliverability in target countries against a capped SMS budget.
• Build-vs-buy is genuinely close: a small internal HTTP adapter is 1–2 days. The package's value is convention and speed-to-first-message, not depth.
• Hard prerequisite: an AllMySMS commercial account. The package does not create the carrier relationship, and adopting it silently commits us to a French carrier for pricing, invoicing, sender-ID registration, and EU compliance.

Technical risk.

• Highest-severity unknown: failure semantics. We must read send() and confirm the channel throws on non-2xx and on error payloads embedded in a 200 OK body (invalid number, unregistered sender, insufficient credit, STOP-listed recipient). If it swallows errors, queued jobs report success while OTPs silently vanish — the worst failure mode for a security-adjacent flow. This is a one-line fix in a vendored copy but a serious blind spot if unverified.
• Abandonment: one star, zero dependents, effectively a single maintainer, reactive framework support. v1.4.0 (June 2025) was a compatibility-only PR adding Laravel 12 with no functional change. Expect a lag window at every future Laravel major.
• Billing surprise: accented characters (common in French copy and brand names) push messages from GSM-7 (160/153 chars) to UCS-2 (70/67), halving the per-segment budget and silently doubling cost.
• Testability: if the channel uses raw Guzzle rather than Laravel's Http facade, channel-level tests require a fork.
• PII exposure: any debug logging of bodies or phone numbers is an incident; we must also audit what the package itself logs.

Key questions to close before commitment.

1. Does the channel throw on non-2xx and on error-in-200 payloads, and where does it surface them?
2. Is AllMySMS the right commercial partner on price, EU/France compliance, sender-ID registration, and deliverability — independent of this package?
3. Does the roadmap need DLR state, inbound replies, failover, per-message cost data, or a vendor SLA? Any "yes" makes this a starting point only.
4. Will engineering wrap the vendor channel behind an internal seam, or call the vendor channel directly from notifications?
5. Who owns the vendored/forked copy when the maintainer stops responding?

Integration Approach

Stack fit.

• Requires a Laravel app on a supported major; composer.json's illuminate/* constraint and PHP floor are the gating facts. Laravel 12 is supported as of v1.4.0 — this dependency no longer blocks that upgrade.
• Idiomatic install: composer require, publish config, set ALLMY_SMS_API_KEY/ALLMY_SMS_FROM (confirm exact names against the published file), keep .env.example in sync.
• Works with both notifiable models and Notification::route('AllMySms', '+33...') for anonymous recipients — the latter is the fastest smoke test.

Migration path.

• Purely additive where SMS doesn't exist: no schema change, no data migration, no service extraction.
• Where an SMS provider already exists: introduce an internal SmsChannel seam first, delegate to the existing provider, then swap the delegate to the AllMySms channel behind it. Notifications reference our channel, never the vendor class — provider replacement becomes a one-file change.
• Vendor or subclass rather than editing the dependency in place: subclass AllMySmsMessage for template()/from() helpers and subclass the channel to fix error semantics, so composer update isn't a merge conflict.

Compatibility and configuration hygiene.

• Pin ^1.4. Treat minor bumps as review-required, not auto-merged.
• Config caching is a live failure mode: a stale cached config in a container yields a swallowed API-key error that looks like "works locally, silent in prod." Make config:clear/re-config:cache part of the deploy runbook.
• Drive staging vs. production through config/env (different sender ID or sandbox, spend cap), never app()->environment() branches inside a notification.

Sequencing.

1. Decision gate (product, not engineering): confirm AllMySMS commercial terms, EU sender-ID registration path, and target-country deliverability. Do not start code before this is settled.
2. Spike, time-boxed (~1–3 days): staging API key, hard-coded number via Notification::route(), verify delivery and inspect raw response bodies. Confirm the error-semantics question here, not in production.
3. Seam: introduce internal SmsChannel; vendor/fork the driver under our namespace if error handling or Guzzle→Http changes are needed.
4. Message hygiene: centralise formatting in one place; E.164 normalisation on the way in; ASCII-only or deliberately segmented bodies; sender ID as config default.
5. Pilot on a low-risk flow (order status, appointment reminder) before touching OTP. Measure delivery rate and per-segment cost against a capped budget.
6. Promote to security-adjacent flows (OTP) only after failure semantics and monitoring are proven — with alerting on non-delivery, not just on job success.

Operational Impact

Maintenance.

• Own it as internal code, not as a dependency. Budget a small but recurring allowance: a compatibility review at each Laravel major, plus a decision point if upstream goes quiet. MIT makes forking legal and cheap; it does not make maintenance free.
• Assign a named owner for the vendored copy and the AllMySMS account. Unowned single-maintainer dependencies rot silently.

Support.

• No upstream SLA and effectively one maintainer — bugs get fixed on their timeline or ours. Commercial support, if any, comes from AllMySMS, not from the package.
• Mitigate with the seam: a fork of ~150 lines is a known quantity, not an escalation risk.

Scaling.

• Appropriate for low-to-moderate, one-way transactional volume. Not appropriate for marketing broadcast.
• No rate-limit handling in the package: throttle explicitly at the job layer (RateLimited middleware or ->delay()) for bursts and bulk sends.
• Cost scales with segments, not messages. Without per-message cost analytics in the package, instrument it ourselves or accept that the invoice is the only signal.

Failure modes to design against.

• 200-with-error-body: job reports success, message never lands. Detect at spike time; fix in the vendored copy; alert on provider error codes in the response body.
• Stale config cache: silent missing credentials in production. Deploy runbook item.
• Unregistered or rejected sender ID: messages dropped or rewritten in EU/FR. Provision before deploy.
• STOP-listed or invalid numbers: provider-side rejection, possibly billed. Normalise and validate numbers on the way in; guard channels on verified phone numbers.
• Unicode segment doubling: cost and truncation surprise. Enforce a character budget in one formatting function.
• No DLR: "did it land?" is unanswerable from the package. Any delivery-rate metric requires supplementary engineering — plan it as a roadmap item, not an assumption about a future version.
• PII leakage: OTPs or numbers in logs. Scope debug logging behind a flag and audit Log:: calls in the channel before production.

Ramp-up.

• Low for any Laravel developer: publish config, route the number, dispatch a notification — well under a day of learning.
• The non-obvious ramp-up is operational, not technical: env var checklist, staging sender ID, config-cache step, spend cap, and a documented kill switch (feature flag or channel removal in via()) so SMS can be disabled without a deploy.
• Keep the first-hour goal explicitly "prove delivery to a real handset," not "build the feature." That framing is what stops an OTP path from going live on an unverified error-handling story.