- How do I install pusher/pusher-push-notifications in a Laravel application?
- Install it with Composer using composer require pusher/pusher-push-notifications. There is no official Laravel service provider or notification channel, so add the Beams instance ID and secret key to your environment and config, then bind a configured PushNotifications client as a singleton in a service provider. Inject that client into queued jobs or a custom notification channel rather than creating it ad hoc in controllers.
- Does this package provide a Laravel notification channel for push notifications?
- No, the SDK is framework-agnostic and does not ship a Laravel notification channel. You can build a small custom channel that resolves the configured Beams client and calls publishToInterests or publishToUsers. Keep the channel behind a provider-agnostic push interface so your application is not hard-coded to Beams.
- How should I configure Pusher Beams credentials in Laravel?
- Store the Beams instance ID and secret key in environment variables and expose them through config/services.php or a dedicated config/pusher-beams.php file. Bind the SDK client as a singleton using those config values, and keep secrets out of version control. Plan for secret rotation and restrict access to the credentials because they authorize server-side publishes.
- Which PHP and Laravel versions are compatible with pusher/pusher-push-notifications?
- The package has no Laravel-specific constraints, so compatibility is mainly a question of its PHP version constraint and Composer dependency conflicts, especially with your HTTP client. Check the SDK's PHP requirement against your Laravel runtime and test on each target Laravel version in CI. Client-side Beams SDK and platform requirements must be validated separately.
- How do I send push notifications to interests or specific users with the SDK?
- Use the client's publish methods such as publishToInterests or publishToUsers from a queued job or custom notification channel. You need to model device interests and authenticated users in Beams and keep those mappings current as devices and sessions change. Batch publishing is supported, but you should still monitor responses and delivery failures.
- Can I test Pusher Beams integration without sending real push notifications?
- Wrap the SDK client behind your own interface and fake that interface in unit tests so you can assert which publish calls your application makes. For integration tests, use a Beams sandbox or test instance where available and avoid targeting production devices. Delivery behavior on real iOS, Android, and web clients still needs separate end-to-end validation.
- Is pusher/pusher-push-notifications production-ready and actively maintained?
- It is the official MIT-licensed Pusher Beams server SDK with commercial backing from Pusher, but public adoption signals are thin, with around 55 GitHub stars and no dependent packages listed. Before committing, verify release cadence, PHP and Laravel compatibility, dependency conflicts, rate limits, and the publish API's retry and idempotency semantics. Also confirm pricing, quotas, SLA, data residency, and multi-tenant isolation requirements.
- What are the alternatives to Pusher Beams for Laravel push notifications?
- Alternatives include sending directly through FCM and APNs, using another managed push provider such as OneSignal, or adopting existing Laravel notification channels for those services. The best choice depends on platform coverage, client SDK requirements, pricing, SLA, and how much device-token management you want to own. Keep a provider-agnostic push interface so you can run Beams in parallel with an existing path and compare delivery metrics.
- How should I handle queues, retries, and failed sends with this SDK?
- The SDK is a thin HTTP API client and does not add Laravel queue, retry, or idempotency behavior by itself. Dispatch publishes from queued jobs with an explicit retry and backoff policy, log responses, and define a fallback path if Beams is unavailable. Confirm the publish API's idempotency semantics before retrying sends that may have already been accepted.
- Do I need client-side work for device registration with Pusher Beams?
- Yes. This package is only the server SDK; registering devices, requesting notification permissions, and integrating the Beams client SDKs for iOS, Android, and web remain separate client-side workstreams. The server side can publish to interests or users only after those devices and users are modeled in Beams. Budget for token and interest lifecycle cleanup as part of the overall feature.