Pushwoosh Laravel Package

Product Decisions This Supports

• Push channel architecture: decides whether push goes through Laravel's unified Notification facade (one code path for mail, SMS, and push) or through a native SDK integration per platform. This package is the "unified" answer.
• Build vs. buy on delivery infrastructure: Pushwoosh owns device registry, segmentation, scheduling, and delivery. The package is only the adapter. Adopting it lets you defer building a device-token service and campaign tooling.
• Roadmap sequencing for mobile engagement: transactional push (order shipped, message received, payment failed) can ship as a Notification class in days instead of a native-platform sprint.
• Multi-channel orchestration and user preferences: because it plugs into via(), per-user channel preferences, quiet hours, and opt-outs become a product feature you can ship rather than a bespoke integration.
• Vendor consolidation: if Pushwoosh is already in the stack for marketing/lifecycle campaigns, this makes it the single push vendor instead of standing up FCM/APNs direct alongside it.
• Exit-cost analysis: a thin wrapper means switching push vendors later is a change to notification classes, not a rewrite. That materially de-risks the buy decision and should be stated explicitly in the vendor review.
• Framework upgrade budgeting (new in v4.0.0): the only thing this release does is track Laravel 13. Read that as the package's maintenance mode — "kept compatible with current Laravel, not actively developed." Any roadmap that spans a Laravel major upgrade should carry a small line item for bumping and re-testing our fork's compat, rather than assuming a community release will land in time.

When to Consider This Package

Consider it when: the backend is Laravel; Pushwoosh is already selected or contracted; the need is transactional and lifecycle push rather than rich in-app messaging; the team wants to avoid owning APNs/FCM token plumbing; and the org is small enough that the Pushwoosh console can carry segmentation and campaign management.

Look elsewhere or proceed cautiously when:

• Community signal is essentially zero — 3 stars and 0 dependents. v4.0.0 shows the package is being kept compatible with new Laravel majors and has picked up an outside contributor, so "abandoned" is too strong — but this is still a very small project with no dependents to catch regressions. Treat it as unvalidated; budget for forking it and owning it internally. MIT makes that straightforward.
• Pushwoosh is not already chosen. A ~200-line adapter should not be the reason a six-figure vendor contract gets signed. Run the vendor decision first, then pick the glue.
• You need full payload control, cost control, or low latency — direct FCM/APNs or a higher-adoption Laravel push package may be the better call.
• You need API surface beyond "send" — verify it covers device registration/sync, deep links, rich media, delivery receipts, and data payloads. Thin channels frequently expose only the send call. v4.0.0 adds no feature surface, so anything missing here still has to be added in our fork.
• Version constraints don't match your app. v4.0.0 is a major bump landing Laravel 13 support; a major version on a package this size almost certainly also raises the PHP floor and/or drops older Laravel majors. Check composer.json constraints against your stack before it lands in a sprint, and assume the upgrade is a scheduled maintenance task with a queue/notification regression pass — not a drop-in composer update.
• You are still on an older Laravel major. Confirm the new major didn't drop support for your version before planning any upgrade; if it did, stay pinned on 3.6.0 and let your fork carry the compat work.

How to Pitch It (Stakeholders)

For executives: this is a low-cost, low-risk way to add push notifications to the Laravel app we already run, with no new infrastructure and no lock-in — it sits on Laravel's notification abstraction, so changing push vendors later is a small code change rather than a re-platform. The latest release (v4.0.0) is maintenance only: it adds Laravel 13 support and a new outside contributor, which tells us the package is being kept alive rather than actively developed. Community adoption is still negligible, so my recommendation is unchanged: adopt it as an internally owned fork with a named maintainer and a pinned version, not as an unqualified third-party dependency. Total engineering exposure is measured in days for the initial integration, plus a small recurring cost each time we cross a Laravel major.

For engineering: it's a small MIT-licensed notification channel — a PushwooshChannel implementing send(), a service provider, and a config file. Audit cost is low and vendoring is easy. We inherit Laravel's queueing, retries, and per-user channel preferences for free. v4.0.0 is a single PR adding Laravel 13 support — no new features, no API changes, no deprecations beyond whatever the major bump drops in framework/PHP support. So the delta on our side is a compatibility check, not a re-review. The real risk remains upstream abandonment, and the mitigation is the same: fork, pin, and own the device-token sync ourselves. Two decisions needed from you: confirm the Pushwoosh contract is real, and confirm the API calls we need (registration, deep links, receipts) are covered by the package or have to be added in our fork — v4.0.0 doesn't move that question.