Smsup Api Bundle Laravel Package

Product Decisions This Supports

• Vendor selection for SMS delivery (Spain/EU): The only real product decision this package informs is whether smsup.es is an acceptable SMS provider. The package itself is a thin Symfony2 service wrapper around an HTTP API — it encodes the provider's request shape (sender, destination, message, credentials), not product logic. Evaluate the provider (delivery rates, sender-ID/alphanumeric support, Spanish regulatory handling, per-SMS pricing, delivery receipts), not the bundle.
• Build vs. buy for the integration layer: This is a ~50–100 line HTTP client in disguise. A PM should treat it as a reference implementation to copy, not a dependency to install. Decision: DIY with Laravel's Http facade or Symfony's HttpClient (≈1–2 dev-days), versus adopting a third-party wrapper you don't control.
• Framework fit / roadmap gating: The package is a Symfony2 bundle, not a Laravel package. Symfony2 has been end-of-life since 2015 (full EOL 2018). If your roadmap is Laravel 10/11+ or Symfony 6/7, this package is not adoptable as-is — it's a porting exercise. That's a "no" for the roadmap, and a "yes, read the source" for the spike.
• Channel strategy for notifications: Useful as a forcing function to ask whether SMS is even the right channel (vs. push, email, WhatsApp) and whether you need a provider abstraction. If SMS is transactional (OTP, delivery updates), you almost certainly want a multi-provider abstraction from day one, which this bundle does not offer.
• Not supported: no delivery-receipt/webhook handling, no inbound SMS, no templating, no retry/queue semantics, no rate-limit handling, no 2FA primitives. Don't scope features against this package's surface area — it has almost none.

When to Consider This Package

Consider (narrowly) if:

• You have a live, maintained Symfony 2.x application that must send SMS through smsup.es — i.e., you're maintaining legacy, not building.
• You want a 10-minute read of the provider's API contract before writing your own client; the bundle documents the request/response shape.
• smsup.es is already a procurement-approved vendor and you need the smallest possible integration to validate deliverability in a pilot.
• You need Spanish-market alphanumeric sender IDs and the provider's compliance story fits.

Look elsewhere (default posture) if:

• You're on Laravel — use Http::withBasicAuth(...)->post(...) behind a SmsSender interface, or an existing Laravel notification channel. There is nothing here worth the dependency.
• You're on Symfony 4+/5+/6+/7 — the bundle's DI config and namespaces won't load; porting costs more than writing fresh.
• You need delivery receipts, inbound messages, retries, queuing, multi-provider failover, template management, or OTP/2FA flows — none are present.
• Supply-chain and maintenance risk matter: 2 stars, 0 dependents, opportunity score 1.73, overall signal 0.01. That means no community vetting, no security response, no CI, no issue triage. Treat as unmaintained sample code.
• You want a provider-agnostic abstraction — this bundle is single-vendor by construction and bakes the vendor into your service container.

Verdict for most PMs: do not adopt. Use as API documentation; ship a 1-file internal client behind an interface so the vendor stays swappable.

How to Pitch It (Stakeholders)

One-liner: A tiny, Spanish-language Symfony2 wrapper for the smsup.es SMS API — useful as documentation of a vendor's HTTP contract, not as a production dependency.

For executives: This is not a build-vs-buy decision of any size. Integrating SMS is commodity work: days, not quarters. The real decision is which provider and whether we keep the provider swappable. Adopting this bundle would couple us to both an unmaintained package (2 GitHub stars, zero downstream users) and a single vendor, with no security-response path. Recommendation: no adoption; we spend ~1–2 engineering days writing a small internal SMS client behind an interface, and we evaluate smsup.es on price, Spanish deliverability, and sender-ID compliance instead.

For engineering: Symfony2 bundle, EOL framework, not Laravel-compatible. Zero dependents and near-zero community signal — assume no upstream fixes. It exposes a thin service over the provider's HTTP endpoint; there's no queuing, retries, receipts, or inbound handling. Read it for the request/response shape, then implement with Http/HttpClient behind an SmsSender contract, with provider credentials in config, queued dispatch, and an idempotency key. Budget: half a day to spike the vendor, one day to productionize with tests and a fake for CI.

Risk register: (1) unmaintained dependency / supply-chain exposure; (2) single-vendor lock-in with no abstraction; (3) framework mismatch forcing a rewrite on upgrade; (4) Spanish-only docs and support surface. All four are avoided by the DIY-client path at negligible cost.