Smsapi Laravel Package

Product Decisions This Supports

• Channel expansion for user notifications. If the product already uses Laravel's notification system (mail, database, broadcast), this package lets you add SMS as a first-class channel with a toSmsapi() method on an existing Notification class — no new messaging infrastructure, queue, or abstraction layer to design. That makes "ship SMS notifications this sprint" a realistic roadmap item rather than a platform project.
• Build vs. buy for the SMS transport layer. The package is a thin adapter over the Smsapi (smsapi.pl) HTTP API, so the real decision is provider, not code: choosing Smsapi as your SMS vendor and adopting this package collapses two decisions into one that costs roughly days, not weeks. Compare against writing the ~150-line client yourself (trivially cheap) — the package's value is convention and maintenance, not capability.
• Regional/segment go-to-market. Smsapi is a Polish provider with EU coverage. This supports a decision to launch SMS-based flows (OTP, transactional alerts, appointment reminders) for PL/EU customers without committing to a global CPaaS like Twilio, which matters when pricing per-message and EU data-residency/GDPR posture are part of the business case.
• Use-case scoping. Good fit decisions: transactional one-way messages (verification codes, order status, reminders), low-to-moderate volume, back-office/admin alerts. Bad fit: conversational two-way messaging, marketing campaigns with heavy segmentation, or anything needing delivery-webhook analytics beyond what the channel exposes.
• Framework-upgrade planning. The 0.9.1 release adds Laravel 13.x compatibility (via Laravel Shift, under the laravel-notification-channels org). This means adopting the package does not create a blocker when the app moves to the next Laravel major — the compatibility work is being absorbed upstream. It does not change the capability set; treat it as evidence the package is on the Laravel upgrade treadmill rather than as a new feature.
• Cost/risk budgeting. With ~24 stars and 0 dependents, treat this as "a thin, org-hosted convenience wrapper with occasional automated maintenance," not a strategic dependency. Budget for a fork (MIT permits it) or an in-house fallback if maintenance lags — the low lock-in is itself a decision input, since ripping it out later is a day of work, not a quarter.

When to Consider This Package

• You are on a supported Laravel version — now including Laravel 13.x as of 0.9.1 (0.9.0 covered the preceding majors) — and already use Laravel Notifications as your outbound messaging abstraction; adding a channel is a one-line via() change.
• Smsapi is already (or is about to be) your SMS vendor — through procurement, existing contract, EU pricing, or sender-ID/registration requirements in Poland/EU.
• Your messaging needs are transactional and modest in volume: OTPs, alerts, reminders. You want the simplest thing that works and can tolerate a community-maintained dependency.
• You have an owner who can read the channel source (it's small), pin a version, and fork if upstream stalls. MIT license makes that a legitimate plan rather than a rescue.
• Look elsewhere when: you need provider-agnostic SMS (multiple vendors, failover, per-country routing) — you want an abstraction layer or a CPaaS SDK, not a single-vendor channel; you need high-volume marketing, two-way conversations, MMS/RCS/WhatsApp, or hard delivery SLAs and support contracts; you need delivery-receipt webhooks and analytics surfaced in-product; your team is not on Laravel Notifications; or your org's policy forbids low-adoption, single-maintainer dependencies in the notification path. In those cases, either build the small client in-house or adopt a provider with a first-party, well-maintained SDK.

How to Pitch It (Stakeholders)

Executives: This is a small, low-risk enabler for adding SMS notifications to our existing Laravel app. It lets us ship OTP and transactional SMS for PL/EU users through Smsapi — an EU-based provider — without building or buying messaging infrastructure. Cost is a few engineering days; the downside is capped because the code is MIT-licensed and thin, so we can replace it quickly if the vendor or the package changes. The latest release (0.9.1) is purely framework compatibility, which tells us the package is still being kept current with Laravel — a maintenance signal, not a product change. It is not a strategic platform bet, and I would not present it as one.

Engineering: A community notification channel for Smsapi, ~1 adapter, MIT. 0.9.1 is a compatibility-only patch adding Laravel 13.x support (PR from laravel-shift, the automation used across the laravel-notification-channels org) — no API changes, no deprecations, no migration work, so it is a safe patch bump. It plugs into Notifiable/via() with no architectural change. Adoption criteria: pin the version, add a fork-and-own contingency in the runbook, and wrap the channel behind our own notification classes so a vendor swap touches one to*() implementation. If we later need multi-vendor routing or delivery analytics, we replace the adapter, not the notification layer.

Recommendation: Adopt conditionally — approve if Smsapi is the chosen vendor and the need is transactional SMS. 0.9.1 doesn't change the decision; it only confirms the package survives a Laravel major upgrade, which removes one small objection. Otherwise, treat it as evidence that SMS-in-Laravel is cheap to do, and make the provider decision first.