Gatewayapi Notifier Laravel Package

Technical Evaluation

What the package actually is. symfony/gatewayapi-notifier is a thin Symfony Notifier transport bridge — roughly a DSN parser, a SmsMessage → POST /rest/messages mapper, and a GatewayApiOptions value object exposing class, callbackUrl, userRef, and label. It does not queue, retry, normalize phone numbers, receive delivery receipts, or validate callbacks. Everything operationally interesting happens around it, not in it. Any prior briefing that describes this as a webhook/retry platform should be corrected before budget discussion.

Architecture fit: poor for a Laravel-first codebase. This is a Symfony Notifier bridge; Laravel has its own notification abstraction (Illuminate\Notifications) with a channel contract and queue semantics. Adopting the bridge introduces a second notification stack alongside the existing one. Symfony components do coexist in Laravel (symfony/console, http-foundation, process are already transitively present), so this is friction, not impossibility — but it's friction with no offsetting benefit when the underlying capability is a single HTTP POST.

Integration feasibility: high, but most of the effort is outside the package. A spike is 2–3 days; production readiness is 1–2 sprints. The disproportionate work is adjacent:

Technical risk.

Key questions for the team.

1. Is SMS the actual requirement? OTP/2FA, transactional receipts, and marketing carry different compliance burdens and different SLAs.
2. Why GatewayAPI specifically? Which geographies and volumes? If the user base is not predominantly Nordic/EU, this is the wrong provider and the package question is moot.
3. Do we already run symfony/notifier? If not, the honest comparison is "this package" vs. "one Laravel service class calling the same REST API" — and the latter wins on dependency count, debuggability, and ownership.
4. What is the delivery SLA, and who owns the DLR endpoint? callbackUrl only says where GatewayAPI sends receipts; we still have to receive them.
5. Who owns the OAuth token, and what is the rotation story?
6. Do we need multi-channel fan-out? That is the one scenario where Symfony Notifier's transport model earns its keep — but even then, Laravel's Notification facade already provides it.
7. What is the fallback policy for a single-provider dependency on a regional gateway for customer-critical messages?

Integration Approach

Recommendation: do not adopt the package in a Laravel-first stack. Reimplement the ~80 lines it saves. The bridge's value is making GatewayAPI a first-class citizen of Symfony Notifier. If we don't run Symfony Notifier, we inherit the dependency tree without the abstraction benefit.

Preferred path (Laravel-native).

• App\Services\Sms\GatewayApiClient — a single service using Http::withBasicAuth($token, '') against https://gatewayapi.com/rest/messages, with sender, message, recipients[].msisdn, plus the same optional fields the bridge exposes (callback_url, user_ref, label, class). ~60–90 lines including error mapping.
• App\Notifications\Channels\GatewayApiSmsChannel implementing Laravel's channel contract, so it plugs into Notifiable::routeNotificationFor() and existing Notification::send() calls.
• App\Jobs\SendSms (ShouldQueue, $tries = 3, exponential backoff, failed() handler) for async delivery and retry — capability the DSN example implies but the package does not provide.
• config/services.php entry for token and sender, sourced from the secrets manager. Never a committed DSN.

Alternate path (adopt the bridge) — only if one of these is true: we are mid-migration from Symfony and already run symfony/notifier; or we intentionally standardize on Symfony Notifier's transport model across SMS/Slack/email in a non-Laravel service. In that case, still isolate it behind an internal SmsSender interface so the transport can be swapped.

Compatibility and sequencing.

If the bridge is chosen: pin symfony/notifier to the minor matching our PHP runtime (^7.4 on 8.2/8.3, ^8.1 on 8.4+), and bind Symfony\Component\Notifier\TexterInterface through a container adapter so application code never depends on Symfony types directly.

Operational Impact

Maintenance. The package itself is low-churn — recent release notes are almost entirely "no significant changes" — but Symfony's annual major cadence will force dependency bumps on our schedule, not theirs. MIT licensed, maintained inside the symfony/symfony monorepo, no commercial SLA. Expect scheduled upgrades with occasional breaking changes inherited from Symfony's PHP floor.

Support model. Framework-level support comes from the Symfony community and Symfony security advisories. SMS deliverability, rate limits, and carrier relationships come from GatewayAPI — separate escalation path, separate contract. A production incident may involve two vendors plus our own queue infrastructure; document that chain in the runbook.

Scaling. The bridge is stateless; throughput is bounded by GatewayAPI account rate limits and HTTP client concurrency. Scale is achieved by scaling queue workers, not the package. Watch message segmentation (160 GSM-7 / 70 UCS-2 chars) since cost and rate-limit consumption scale per segment, not per message.

Failure modes to design for.

• 401 on token rotation or misconfigured DSN — alert on auth failures specifically.
• 4xx on malformed MSISDN or unregistered sender ID — pre-validate and normalize to E.164.
• 5xx/timeouts with no built-in retry — the queue job must own backoff and dead-lettering.
• API acceptance mistaken for delivery — DLR endpoint and reconciliation job are mandatory for anything customer-visible.
• Version drift between symfony/notifier minors and our PHP runtime — caught by CI's composer why-not check, not by code review.
• Single-provider outage — circuit breaker plus secondary provider for OTP/transactional traffic.

Ramp-up. A mid-level PHP developer is productive on the bridge or the replacement client in roughly one day. The real learning curve is the surrounding surface — queue semantics, DLR handling, phone normalization, and opt-out/quiet-hours compliance — which is where I'd expect a new engineer to spend their first week. Estimated cost to MVP: 2–3 developer days. Production-grade with DLRs, monitoring, and fallback: 1–2 sprints plus the sender-ID registration calendar time, which should be started immediately since it gates launch independently of code.