Client Laravel Package

Product Decisions This Supports

• Transactional messaging / notifications: Adding SMS-based user notifications (order updates, appointment reminders, delivery alerts, OTP/2FA codes) to a Laravel or PHP product without building a telco integration in-house.
• Build vs. buy: This package represents the "buy/borrow" path for the client layer — it wraps the smsgateway.me HTTP API. The real buy decision is the gateway service itself; the package is a thin convenience wrapper, so treat it as a vendor lock-in decision, not a code decision.
• Feature scoping: Useful for validating demand for SMS in an MVP or internal tool where a single provider abstraction is acceptable. Not appropriate where delivery guarantees, multi-provider failover, or compliance (10DLC, GDPR, opt-out handling) are product requirements.
• Roadmap input: Because the last release was May 2018 and there are zero dependent packages, adopting it implies owning the client code long-term. That is a roadmap cost, not a footnote — budget for a fork or replacement before you ship.
• Use cases that fit: Low-volume internal alerting, prototyping, non-critical notifications in markets where smsgateway.me coverage is strong. Use cases that don't: regulated OTP at scale, anything needing SLAs, or products where SMS is a revenue-critical channel.

When to Consider This Package

Consider it only if:

• You are already committed to smsgateway.me as your SMS provider (the package adds no value otherwise).
• The integration is non-critical, low-volume, or a short-lived prototype.
• Your team is comfortable forking and maintaining a small, unmaintained PHP client — expect to patch for modern PHP/Laravel versions, PSR-18/HTTP client compatibility, and current TLS/API behavior.
• You have verified the gateway's API is still live and the client still authenticates correctly (this must be tested, not assumed, given the 2018 release date).

Look elsewhere if:

• SMS is user-facing and revenue- or trust-critical (OTP, security codes) — you need a maintained SDK with active support.
• You need multi-provider failover or provider abstraction — use a Laravel notification channel or an aggregator (Twilio, Vonage, MessageBird, or a local provider) with first-class framework support.
• You need compliance features (opt-out management, sender ID registration, delivery receipts, audit trails).
• Your stack is Laravel 9+ and you expect native package discovery, typed exceptions, and queue integration out of the box — this package predates those conventions and will likely need adaptation.

Given 25 stars, zero dependents, and a 2018 last release, the honest default is: do not adopt as a dependency; evaluate the gateway directly, or prefer a maintained alternative.

How to Pitch It (Stakeholders)

For executives: This is a small, free PHP wrapper for a third-party SMS gateway. It would let us send SMS notifications quickly, but it has not been updated since 2018, has negligible community adoption, and no downstream packages depend on it. Treat it as a temporary convenience, not a strategic dependency. Recommendation: validate SMS demand with a low-cost provider, but do not build a critical customer-facing feature on this client without budgeting for maintenance or replacement.

For engineering: It is a thin HTTP client around smsgateway.me — low complexity, low risk to evaluate, but effectively unmaintained. Expect to fork it: dependency updates, modern HTTP client compatibility, error handling, and tests are on us. If we proceed, wrap it behind our own notification interface so the provider can be swapped without touching product code.

Decision requested: Approve a time-boxed spike (e.g., one sprint) to test whether the gateway and client still work for our use case, with a pre-agreed exit to a maintained provider if the spike surfaces integration or support gaps.