Php Client Laravel Package

Product Decisions This Supports

• Build vs. buy for the messaging channel. This package resolves the "do we write our own SMS integration?" question in favor of buy: it wraps SMSAPI's REST API (send SMS/MMS/VMS, delivery reports, sender names, contact lists, groups, templates, blacklists, subaccounts) so engineering spends days, not a quarter, on a commodity capability.
• Regional/GEO expansion sequencing. SMSAPI is a Polish gateway with strong PL/EU coverage and local sender-name registration. Adopting it is a decision to prioritize Poland/CEE/EU delivery quality and compliance over global one-vendor coverage — a roadmap commitment worth stating explicitly.
• OTP / 2FA and account-security roadmap. Reliable transactional SMS underpins login verification, password reset, and step-up auth. Whether this package is good enough to unblock the security roadmap is a concrete gate for the next quarter.
• Transactional vs. marketing channel separation. The package covers both one-off transactional sends and bulk/contact-list campaigns. PM decision: do we use one vendor for both, or split transactional (uptime-critical) from marketing (volume/cost-optimized)?
• Multi-channel fallback strategy. Support for VMS (voice) and MMS lets you ship "SMS failed → voice call" fallback for critical alerts without adding a second vendor.
• Data residency and GDPR posture. EU-hosted gateway with contact data stored at the vendor is a product/privacy decision (data processing agreement, retention, right-to-erasure flows) that must be made before launch, not after.
• Where the abstraction layer lives. The package is a thin, single-vendor client. Adopting it implies a product decision to wrap it behind an internal Notifier/SmsSender interface so future provider swaps (Twilio, Vonage) don't touch feature code.
• Procurement / legal gate. NOASSERTION license means the license is not machine-identifiable. That is a blocking review item for commercial distribution — it belongs on the launch checklist, not in a footnote.

When to Consider This Package

Consider it when:

• You are already using, or actively evaluating, SMSAPI as your gateway — this is a first-party SDK, not a generic library, so its value is entirely contingent on that vendor decision.
• Your primary market is Poland / CEE / EU and delivery quality, local sender names, and GDPR-friendly data handling matter more than global reach.
• Your stack is PHP/Laravel and you want a Composer-installable client rather than hand-rolling HTTP calls against the SMSAPI docs.
• Your volume is low-to-moderate and you value speed to market over per-message cost optimization or custom routing.
• You need OTP, transactional alerts, contact/group management, and basic campaign sends from one integration.
• You are comfortable pinning a version and wrapping it: releases are recent (2026-04-09), which signals vendor maintenance.

Look elsewhere when:

• You need global coverage across the Americas, APAC, or Africa — evaluate a global CPaaS (Twilio, Vonage, Infobip) instead.
• You are not on PHP. There is no value here for a Node, Python, Go, or JVM service.
• You want a provider-agnostic abstraction out of the box. This is a vendor client; multi-provider failover, routing, and cost arbitrage are your problem.
• Legal cannot clear NOASSERTION. Ship-blocking ambiguity in an SDK embedded in a commercial product is not worth the argument — either get written clarification from the vendor or use their plain REST API directly.
• You need marketing automation with journeys, segmentation, A/B testing, and analytics — that is an ESP/CRM decision, and this client only sends the messages.
• Ecosystem trust matters: 66 stars and 0 dependents means a thin community safety net. If you require broad third-party validation before adopting a dependency, this fails that bar.
• You need guaranteed SLAs, dedicated IPs, high-volume discounts, or carrier-level routing control — negotiate those commercially with the gateway; the SDK won't provide them.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can ship SMS — OTP, order updates, incident alerts, and basic campaigns — in roughly one to two weeks of engineering instead of building a messaging integration ourselves. This package is the official PHP client for SMSAPI, a Polish gateway with strong EU coverage, recent releases, and the compliance posture we need for EU customer phone numbers. The cost is a vendor relationship plus a legal review, because the license metadata is ambiguous. Recommendation: approve a short spike to validate delivery quality and cost per message in our target markets, and require engineering to wrap the client behind an internal interface so we are never locked in.

For engineering: It's a Composer package wrapping SMSAPI's REST endpoints — sending, delivery reports, contacts, groups, templates, sender names, subaccounts, blacklist. It is a thin, single-vendor client with no dependency graph and low public adoption, so treat it as glue code, not infrastructure: pin the version, isolate every call behind our own sender interface, add retry and idempotency at our layer, and write integration tests against a sandbox rather than mocking the SDK's internals. Assume the vendor's release cadence, not ours, governs upstream fixes.

The honest risks to state up front:

1. License ambiguity (NOASSERTION) — blocking until legal signs off or the vendor clarifies in writing.
2. Vendor lock-in — mitigated only if we own the abstraction layer from day one.
3. Thin ecosystem — 66 stars, 0 dependents; we are early adopters and should budget for reading source rather than Stack Overflow.
4. Regional bias — excellent for PL/EU, not a global answer; a second provider is a near-certain future need if we expand.

Decision requested: Green-light a 1–2 week spike (delivery quality, latency, cost, DPA terms) with a go/no-go at the end, conditional on legal clearing the license.