Smsup Api Bundle Laravel Package

Technical Evaluation

Architecture fit The package is a Symfony 2 bundle, not a Laravel package. That distinction is the whole evaluation. Bundles are bound to Symfony's HttpKernel, DependencyInjection component and Resources/config/services.yml conventions; Laravel has no bundle loader, no AppKernel registration, and no equivalent extension lifecycle. There is no service provider, no extra.laravel auto-discovery block, and no facade. Out of the box it is not installable into a Laravel application in any supported sense.

The functional payload, however, is likely small: an HTTP client that posts a destination number, a sender ID and a message body to smsup.es with an API key, then parses a response. That is the only part worth having. The realistic architecture decision is do not integrate the bundle — extract the API contract and reimplement the transport in Laravel-native code. Estimated effort: 100–200 lines behind an interface.

Integration feasibility Feasibility splits sharply depending on one unknown: whether the repository contains a container-agnostic client class (e.g. a plain Smsupapi/Client object with constructor-injected credentials) alongside the Bundle and DI extension classes. If it does, you can vendor or copy just that class and skip Symfony entirely. If all logic lives inside container-configured services, the bundle has near-zero salvage value and you are effectively reverse-engineering the HTTP calls from source.

Either way, copying source is preferable to composer require. Composer resolution is the primary blocker: Symfony 2-era bundles pin PHP constraints around 5.3–5.5 and typically pull Guzzle 3.x/5.x or Symfony 2.x components, all of which are EOL and will conflict with PHP 8.1+ and Laravel 9+. --ignore-platform-reqs gets the code onto disk but not into a supported dependency graph.

Technical risk

• Abandonment: 2 stars, 0 dependents, score 0.01. No community, no issue triage, no security disclosure path, no evidence of recent commits. Treat as unmaintained source material, not a dependency.
• EOL substrate: Symfony 2.8 reached end of maintenance in November 2018. Anything in the transitive tree inherits that.
• Silent failure risk: SMS clients of this era commonly return status codes rather than throwing, and often parse string responses naively. A misread response means messages reported as sent when they were not.
• No idempotency: retries on an unclassified failure duplicate billable SMS. This is a direct cost line, not just a UX defect.
• Encoding/length: Spanish-language traffic means accented characters, which shift GSM-7 to UCS-2 and change segment count and price. Verify the client does not silently truncate.
• Credential handling: check whether the API key is read from config or hardcoded, and whether request/response logging leaks it.

Key questions

1. Does the repository expose a standalone client class independent of the Symfony container?
2. What HTTP transport (cURL, Guzzle 3/5, Buzz) and what PHP/Symfony constraints are declared?
3. Does the API return structured errors, and does the client surface them as exceptions or return codes?
4. Which API version does it target, and is that version still live at smsup.es?
5. Does the provider now ship an official PHP SDK? If so, this package is superseded and the question is moot.
6. Are delivery receipts (DLR) supported, and by webhook or polling?

Integration Approach

Stack fit Target: Laravel 10/11, PHP 8.2+, Guzzle 7 via the Http facade. The bundle's own stack (Symfony 2, PHP 5.x) is two major eras behind. There is no version of this package that is a peer dependency of a current Laravel app.

Migration path Recommended path is reimplementation, not migration:

1. Read the bundle source in a throwaway container (composer require --ignore-platform-reqs in a scratch directory) purely to extract: base URL, endpoint paths, auth header/param name, request fields, response shape, error codes.
2. Write App\Services\Sms\SmsupClient implementing an SmsSender interface with a single send(string $to, string $body): SendResult method.
3. Bind it in a dedicated SmsServiceProvider, config in config/services.php, secrets in .env (SMSUP_API_KEY, SMSUP_SENDER_ID).
4. Delete the scratch directory. Do not let the tarball enter the repo.

Direct bundling is only defensible if the spike reveals a clean, self-contained client class with no Symfony imports — in which case copy that one file with attribution, drop the Bundle class, the DI extension and Resources/config, and wrap it.

Compatibility

Sequencing Half-day spike to answer the six questions above → decision gate (reimplement vs. adopt official SDK) → adapter + interface → feature tests against a faked HTTP client (never hit the live provider in CI) → queue integration with backoff → observability → provider-lock review at 90 days.

Operational Impact

Maintenance You own 100% of it. Upstream is dormant; there is no one to send a CVE to and no one to merge a PHP 8 fix. Budget the reimplementation as your own code with your own test coverage, and record the provenance (source URL, date copied, what was changed) for licence hygiene.

Support Package support: none. Vendor support for the smsup.es API itself is a separate and likely better channel — escalate API questions to the provider and treat the repository as documentation of last resort. The 0-dependents figure means there is no Stack Overflow surface and no one else has hit your bug.

Scaling Throughput is governed by the provider's rate limits and your account tier, not by the package — which is synchronous and will block the request cycle. Route all sends through Laravel queues with per-provider rate limiting (RateLimited job middleware) and a dedicated queue so SMS backlogs never starve other work. At Spanish-market volumes this is usually tens to low thousands per day; the queue is about latency isolation and retry control, not raw throughput.

Failure modes

• Duplicate sends from retries on ambiguous timeouts — billable and user-visible. Mitigate with a client-side idempotency key or a dedupe window keyed on recipient+body hash.
• Unclassified retries — retrying a 4xx (invalid number, insufficient balance) burns quota and hides the real error. Classify: retry 5xx/timeout only.
• Silent success — response parsed as success when it was a rejection. Test the parser against captured real payloads for each error code.
• Encoding drift — accented Spanish text triggering UCS-2 segmentation, doubling cost per message. Assert segment counts in tests.
• Credential exposure in logs or exception traces.
• Vendor lock — hardcoding smsup.es calls across the codebase. The SmsSender interface exists to make a second provider a config change.

Ramp-up Low for any PHP developer — a single HTTP call and a response parser. The real onboarding cost is the trap: a package on Packagist with a version number reads as maintained. Document explicitly in the repo that this is vendored source with no upstream, so a future developer does not attempt a composer update and spend a day on a dependency graph that cannot resolve.