Serwersmsbundle Laravel Package

Product Decisions This Supports

• Vendor selection for SMS/OTP delivery in the Polish market. SerwerSMS.pl is a regional SMS gateway; this bundle is the Symfony-side adapter for its API v2. It is relevant only if SerwerSMS is already (or is being considered as) your SMS provider for Poland/CEE, typically for OTP, transactional alerts, or marketing sends.
• Build vs. buy for the integration layer. The package is a thin transport wrapper around the SerwerSMS HTTP API. The realistic question is not "should we build an SMS client" but "is wrapping this API worth a dependency versus 100–200 lines of HTTP calls we own." Given the package's maintenance profile, leaning toward a small in-house client (or the vendor's raw PHP client) is the defensible default.
• Framework-fit decision. Despite being commonly filed under Laravel/PHP, this is a Symfony bundle targeting Symfony 2/3/4. For a Laravel codebase it is not a drop-in: you'd consume the underlying client library and wire it into the container yourself. That changes the effort estimate and weakens the "install and go" argument.
• Roadmap input for localization/expansion. If the roadmap includes Poland or CEE launch, an SMS vendor decision and a per-country provider abstraction become real workstreams. This package informs the "regional provider" option but argues for keeping SMS behind your own interface so providers are swappable.
• Risk register / tech-debt input. Last release May 2019, 2 stars, 0 dependents, no visible community. Treat as "vendored snippet," not "supported dependency," in any architecture or security review.
• Not supported: choosing this as a strategic platform component, a shared internal standard, or anything on a compliance-sensitive path without a self-owned fork.

When to Consider This Package

Consider it when:

• You are on Symfony 2/3/4 (legacy) and already committed to SerwerSMS.pl as the SMS provider.
• You need a quick proof of concept for SMS sending in a Polish-market MVP and want to skip reading the API docs.
• The integration is low-stakes and low-volume (internal notifications, dev/test environments, a single notification type).
• You are comfortable pinning the dependency, reading the ~small source, and accepting that you — not upstream — own fixes.

Look elsewhere when:

• You are on Laravel or any non-Symfony framework. Use serwersms/serwersms-php-client directly, or write a small Guzzle/HTTP client behind your own SmsSender interface.
• You are on Symfony 5/6/7. The bundle targets 2/3/4 and is unmaintained; expect friction or outright incompatibility with modern service-container conventions.
• SMS is business-critical (OTP for auth, transactional alerts with SLAs). You need a maintained SDK, documented rate-limit/retry behavior, delivery-receipt handling, and a vendor with a support contract — none of which this package provides.
• You need multi-provider routing, failover, templating, or cost optimization across countries. Build a provider abstraction; do not couple to one regional gateway's bundle.
• Security/procurement review is mandatory. Two stars and zero dependents means no external scrutiny; you are the reviewer.

Reasonable middle path: use the vendor's raw client library, wrap it in a 1-file adapter you own, and skip the bundle entirely. You keep vendor API convenience without inheriting an abandoned framework integration.

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source connector between a PHP application and SerwerSMS.pl, a Polish SMS gateway. It is not a platform or a paid product — it is roughly a day of integration work packaged up. The strategic decision it informs is which SMS vendor we use for Poland/CEE and how much we let a single regional vendor shape our code. My recommendation: treat SMS as a commodity behind our own internal interface, so the vendor — and this connector — can be swapped in an afternoon. Do not let a 2-star, last-updated-2019 component become load-bearing.

To engineering: It's a Symfony bundle (2/3/4) for the SerwerSMS v2 API, Apache-2.0, last release May 2019, effectively no community. For Laravel or modern Symfony, don't install the bundle — use the vendor's PHP client and wrap it in a thin SmsSender adapter with our own retry, logging, and error mapping. Budget roughly half a day to a day; most of it is credentials, error handling, and testing, not the API call itself. Pin the version, vendor the code if we adopt it, and keep provider-specific types out of our domain layer.

Ask: approve the internal-adapter approach and a short spike to confirm SerwerSMS pricing, delivery-receipt support, and SLA against one alternative provider before we commit to it for the Poland launch.