Smsapi Bundle Laravel Package

Product Decisions This Supports

• SMS as a delivery channel — the only concrete decision this package informs is "should we send transactional SMS (OTP/2FA, order status, appointment reminders, dunning) via SMSAPI, and how do we wire it in?" It answers the integration mechanics question, not the should we question.
• Build vs. buy for a provider SDK — it is a thin Symfony DI wrapper around the smsapi/php-client library. The PM-relevant insight: the wrapper is negligible work, so the real buy-vs-build decision is about the underlying client, not this bundle. Do not treat "1 package exists" as evidence that integration effort is de-risked.
• Market/roadmap scoping — SMSAPI is a Polish provider with strong PL/EU coverage and PLN-denominated pricing. This is relevant only if the roadmap includes Poland/CEE or EU data-residency requirements; it is a poor fit as a global default.
• Architecture compatibility gating — the package name says "bundle," and it is Symfony 2, not Laravel. That is a decision input in itself: adopting it would mean either running a Symfony 2 service (EOL since 2018) or writing a bridge. Neither is a "just install it" story, so it should be logged as rejected on architecture grounds, not deferred as a nice-to-have.
• Vendor/concentration risk tracking — 1 star, 0 dependents, single-maintainer, last release 2016-06-01. Useful as a concrete example when arguing for a "no unmaintained dependencies in the payment/notification path" policy.

When to Consider This Package

Consider it only under a narrow and unlikely conjunction:

• You are on Symfony 2.x (or a legacy app you cannot migrate off it) and already standardized on SMSAPI as the provider.
• You want the DI service definition boilerplate done for you and are willing to fork and maintain it yourself.
• You have read the source (~a config + service definition) and concluded that vendoring those few lines into your own bundle is more overhead than forking this one — which is rarely true.

Look elsewhere in essentially every other case:

• Laravel (your stated context): this is not a Laravel package. No service provider, no facade, no publishable config, no queue integration, no Notification channel. You would be building the integration anyway; skip the wrapper entirely.
• Modern Symfony (5/6/7): incompatible service/DI conventions and long-dead bundle standards; the wrapper saves nothing.
• Direct use of the SDK: smsapi/php-client is the maintained artifact and can be used from any PHP framework via a small adapter — that is the honest "buy" option here.
• Framework-native alternatives: a Laravel notification channel or a generic provider abstraction (Twilio, Vonage, Plivo, or a provider-agnostic SMS gateway) gives you failover and testability this bundle never will.
• Anything on a security or compliance review path: 9-year-old code with zero dependents and no CVE surface monitoring is not defensible in an audit for a channel that touches 2FA.

Decision rule for the PM: if the answer to "who patches this when SMSAPI changes their API?" is "us, in a fork of a 2016 Symfony 2 bundle," the answer is no.

How to Pitch It (Stakeholders)

Executive summary: We evaluated kch/smsapi-bundle as a way to add SMS to the product and recommend not adopting it. It is a Symfony 2 bundle — the wrong framework for our Laravel stack — last released in June 2016, with one maintainer, one star, and no downstream dependents. It contains almost no logic: it wires the official SMSAPI PHP client into Symfony's container. Everything valuable lives in the underlying client, which we can use directly.

Engineering summary: Treat this as a historical artifact, not a dependency. The cost of the wrapper is a handful of lines; the cost of owning an unmaintained Symfony 2 bundle (and its EOL framework assumptions) is ongoing. Recommended path: evaluate smsapi/php-client behind our own thin interface, plus a Laravel notification channel, so the provider is swappable. If we choose SMSAPI for PL/EU coverage, we get its pricing and delivery quality without inheriting the bundle's decade of drift.

What this changes in the plan: nothing about whether we ship SMS — only how. It reduces estimated integration effort to "small adapter," removes a dependency-review flag, and keeps the provider decision (SMSAPI vs. global gateway) open, which is the decision that actually moves cost and coverage.