Gatewayapi Notifier Laravel Package

Product Decisions This Supports

What it is, in product terms: a ~200-line MIT-licensed adapter that lets a Symfony application send SMS through GatewayAPI (a Nordic/EU-focused gateway) via Symfony's Notifier component. It registers a gatewayapi://TOKEN@default?from=FROM DSN and exposes a handful of provider fields (class, callbackUrl, userRef, label) through a GatewayApiOptions object. That is the whole scope.

Decisions it genuinely informs:

• SMS use-case scoping. Which messaging jobs are we actually shipping — OTP/2FA, transactional notifications, or marketing? Each carries different compliance, cost, and latency requirements. The package supports all three equally; it does not help you choose.
• Build vs. buy, narrowly. The "buy" option here saves roughly 60–90 lines of HTTP client code. That is the entire buy-side value. If the team is Laravel-first, the build side is cheaper than the integration overhead.
• Provider selection. GatewayAPI is strong in Denmark/Nordics/EU and thin elsewhere. This package is a downstream consequence of that choice, not an input to it. If the user base isn't predominantly Nordic/EU, the provider decision — and therefore this package — is moot.
• Roadmap sequencing for the surrounding work. The package does not provide retries, delivery-receipt (DLR) handling, idempotency, opt-out management, quiet hours, or provider failover. Those remain roadmap items with real cost, and they should be planned as such. The callbackUrl option only tells GatewayAPI where to send a receipt; we'd still have to build and secure that endpoint.
• Feature-flag / pilot framing. A time-boxed spike (2–3 days to first send) is a reasonable product experiment; a production commitment (1–2 sprints plus 1–3 weeks of calendar lead time for sender-ID registration with carriers) is a program decision, not a package decision.

Decisions this package should not be cited as supporting:

• Anything described as a webhook ingestion platform, "automatic retries," "idempotent callback processing," or PCI/PSD2/Stripe relevance. None of that is true of this package. If prior internal documents said so, correct the record before any budget conversation, because the business case they describe would justify a much larger investment than this warrants.
• A multi-channel notification strategy for a Laravel codebase. Laravel's own Illuminate\Notifications already covers channel fan-out; adopting this adds a second parallel stack.

When to Consider This Package

Reasonable to adopt when all of these hold:

• The application is Symfony-first and already runs symfony/notifier — the package then makes GatewayAPI a first-class transport with near-zero marginal cost.
• SMS traffic is predominantly Nordic/EU numbers, matching GatewayAPI's coverage strength.
• The PHP baseline matches the Symfony minor you pin to (Symfony 8.x requires PHP ≥ 8.4; Symfony 7.4.x targets 8.2/8.3). Verify with composer why-not before committing.
• SMS is a convenience channel, not a revenue-critical path — or you have separately budgeted the DLR endpoint, retry policy, and fallback provider.
• The team is comfortable owning the OAuth token lifecycle; the credential is embedded in the DSN.

Look elsewhere when any of these hold:

• Laravel-first stack. Prefer a ~60–90 line GatewayApiClient on Laravel's HTTP client plus a NotificationChannel adapter. You avoid pulling symfony/notifier, symfony/http-client, symfony/options-resolver, and their transitive contracts for one POST request, and you keep the whole path debuggable in one place.
• You need delivery receipts or retries. Not in scope here; you build them either way, so the package provides no head start.
• You need multi-provider failover or a circuit breaker. Abstract behind your own interface rather than binding to one bridge.
• You need vendor SLA or support. MIT community package; the Symfony name is a quality signal, not a commercial contract for your integration.
• You need an actively evolving feature set. Release notes across two years are dominated by "no significant changes"; the only feature addition was the label parameter. It is stable, not developing.
• Traffic is outside the Nordics/EU. Compare Twilio, Vonage, or SNS instead; the package is irrelevant to that comparison.

Reading the health signals correctly: 6 stars and 0 dependents is an artifact of Symfony's subtree-split repositories — real usage flows through symfony/notifier. Do not read it as abandoned; equally, do not read it as proof of maturity. The release cadence is healthy and current (latest 8.1.0).

How to Pitch It (Stakeholders)

One-line summary for executives: This is a small, free, well-maintained connector that lets a Symfony application send SMS through GatewayAPI. It is plumbing, not a platform — the strategic decisions are the SMS use cases, the provider choice, and the compliance work around it.

Framing the value honestly. The package's contribution is measured in saved lines of code, not in capability. Treat it as a low-risk, low-cost enablement of SMS in a Symfony service. Do not attach platform-level expectations to it, and do not put it at the center of a roadmap slide.

What the actual investment looks like (most of it unrelated to the package):

For engineering: if we're on Laravel, recommend against taking the dependency and instead reimplementing the same REST call natively — it is smaller, faster to debug, and keeps us to a single notification abstraction. If we're mid-migration from Symfony with symfony/notifier already wired, adoption is straightforward and appropriate.

The one thing to say out loud: this package sends SMS. It does not receive webhooks, does not retry, and does not validate callback payloads. Any earlier framing that suggested otherwise should be corrected before a budget decision is made.

The ask: approve a small spike and a provider/compliance decision, not an integration project. The budget conversation should be about the SMS program — carrier registration lead time, DLR handling, and fallback policy — because that is where the cost and the risk actually sit.