Octopush Notifier Laravel Package

Product Decisions This Supports

• Adding an SMS channel to the roadmap. This is a thin transport bridge that lets the app send transactional SMS (OTP/2FA, order and delivery alerts, appointment reminders, payment failures) through Octopush. It is not a push-notification, email, or campaign/marketing tool — the bridge sends one transactional message per notification, with no list management, scheduling, or bulk campaigns. If internal notes describe it as "push notifications," correct them before they reach a roadmap review.
• Provider choice and cost optimisation. Octopush is a French provider with three explicit routes exposed as a single config flag: XXX (low-cost), FR (premium French), WWW (world). That makes route selection a product/pricing lever, not just a config detail — per-message cost and deliverability for French numbers differ by route, so the PM can price an SMS feature (e.g. "OTP costs X per auth") and tune it later without a code change.
• Build vs. buy: buy the wrapper, own the abstraction. The package replaces hand-rolling an Octopush HTTP client. Realistic effort: direct Http calls are ~half a day but leave you owning retries, payload drift, and error mapping; adopting this bridge plus wiring Symfony Notifier into Laravel is roughly 1–2 days and hands you Symfony's transport/channel conventions, an in-tree test suite, and a supported upgrade path. Choose based on whether you want to own a client or inherit a framework contract.
• Multi-provider resilience as a designed-in option. Because the bridge plugs into Symfony Notifier, Octopush can be composed with other SMS transports under Notifier's failover/round-robin transport strategies. That turns "we picked Octopush" from a hard lock-in into a reversible decision — a strong argument when procurement or a regulator later pushes back on a single vendor.
• EU/GDPR and data-residency posture. For French/EU user bases, routing SMS through an EU-headquartered provider is a cheaper and easier compliance story than a US-first provider, and is defensible in a DPA review without an engineering project.
• Roadmap sequencing. Use it as the low-cost path to ship a first SMS capability (auth codes are usually the wedge) and defer investment in delivery-receipt handling, per-route analytics, and fallback orchestration until volume justifies them.

When to Consider This Package

Adopt if:

• Octopush is already (or is about to be) your SMS vendor — this package is worthless without an Octopush account and API token.
• Your application is Symfony, or your Laravel app is genuinely willing to carry symfony/notifier + symfony/http-client and a small service-provider/adapter to expose it to Laravel's notification system. Be explicit in the decision record: adopting this package means adopting Symfony Notifier, not just a 200-line class.
• You need a small, transactional SMS surface (OTP, alerts) and value a maintained, MIT-licensed bridge over a bespoke client.
• Multi-channel notification plumbing (SMS alongside email/chat) is on the roadmap — Notifier's channel abstraction earns its keep then; for SMS alone it is arguably overhead.

Look elsewhere if:

• You are a Laravel-first shop with no appetite for Symfony Notifier. A Notification channel backed by the Http facade will be simpler, easier for the team to debug, and won't drag in an unfamiliar component. This is the default choice for most Laravel apps.
• You need anything beyond transactional SMS: campaigns, contact lists, scheduling, MMS/rich media, WhatsApp/RCS, or self-serve delivery analytics. The bridge exposes none of Octopush's platform features.
• You need delivery receipts. The bridge is fire-and-forget; DLR/callback handling and status reconciliation are your build, not the package's. Budget for that separately or the "did the OTP arrive?" support queue becomes the feature's reputation.
• Octopush's per-route pricing or French sender-ID/opt-out (ARCEP, STOP handling) obligations don't fit your markets or legal posture.
• You require a vendor with a support contract, SLA, and a named account team — Octopush support is a commercial relationship you must negotiate; this package contributes nothing there.

Risk note for the decision log: GitHub shows 8 stars and 0 dependents. Do not read that as quality — this repo is a read-only split of the Symfony monorepo, so issues and PRs live in symfony/symfony and support flows from Symfony's release cadence (releases track Symfony 7.4/8.0; v8 requires PHP ≥ 8.4). The real signal is: zero independent community, so every answer comes from Symfony core docs. Conversely, the maintenance burden is genuinely low and predictable — which is the argument to make.

How to Pitch It (Stakeholders)

For executives (one paragraph): "We can add transactional SMS — starting with login codes and delivery alerts — without building or owning a vendor integration. Octopush is an EU-based SMS provider with tiered routing (cheap, premium-French, worldwide), so we can price the feature per message and adjust cost later via configuration rather than engineering. We inherit the integration from Symfony's maintained, MIT-licensed component library, so there's no licence cost and no lock-in: provider swaps are a config change, and we can run two SMS providers side by side for resilience. Estimated engineering cost is 1–2 days versus roughly a week to build and indefinitely maintain a bespoke client. Two things we are not buying: delivery-receipt tracking and marketing campaigns — those are separate scope and should be explicitly out of the first release."

For engineering (the honest framing):

• The package is a transport bridge, not an SDK. It's a small class plus a factory that maps a DSN (octopush://USERLOGIN:APIKEY@default?from=FROM&type=TYPE) to Symfony Notifier's Transport/Channel contracts. The real dependency you're taking on is symfony/notifier and symfony/http-client.
• Under Symfony, integration is config-only. Under Laravel, the work is: register Notifier's services (or hand-wire the transport), keep guzzlehttp/guzzle and symfony/http-client from colliding, bind credentials via config/services.php, map Octopush errors to your existing exception/retry conventions, and wrap sends in queued jobs so SMS latency never touches a request cycle.
• Credentials and sender IDs are DSN/env-driven — treat the API key as a secret, and pin the sender per environment.
• Missing and staying missing unless we build it: delivery-receipt webhooks, per-message cost attribution, retry/circuit-breaker policy, and failover to a second provider (available via Notifier's transport strategies, but it's configuration we own and must test).
• Recommendation: spike the direct-Http version first if we only need SMS — it's faster to ship and easier to reason about. Adopt this bridge deliberately if we're standardising on Notifier for multi-channel notifications or want the failover story.