- How do I install ankurk91/fcm-notification-channel in Laravel?
- Install it with Composer using composer require ankurk91/fcm-notification-channel. Then add 'fcm' to the via() array of a Laravel notification and implement a toFcm() method that returns the package's message builder. The package fits Laravel 5.5 through 9-era notification flows, but verify that your Laravel and PHP versions match its 2022 constraints before adopting it.
- Does this package support Laravel 10 or Laravel 11?
- No verified support exists for Laravel 10 or 11; the package was last released in February 2022 and targets the Laravel 5.5 to 9 era. Because the repository is archived, you should not expect compatibility updates, dependency patches, or fixes for newer framework versions. Treat Laravel 10 or 11 use as unsupported unless you fork and maintain the package yourself.
- How do I configure the FCM server key for this Laravel channel?
- Configuration is built around the legacy FCM server key used by the retired fcm.googleapis.com/fcm/send endpoint, typically supplied through an environment variable and the package config. Use the package's 2022 README for the exact key name and publishing steps, because the repository is archived and no longer updated. If your Firebase project has already migrated to HTTP v1 with OAuth2 service-account credentials, this channel will not authenticate correctly.
- How do I send an FCM push notification to a device token in Laravel?
- Create a Laravel notification, add 'fcm' to its via() method, and return a message from toFcm() that targets the device token. The channel handles the HTTP call to FCM, so your domain model and queue setup stay unchanged. On modern Firebase projects the send will fail with 401 or 404 responses because the legacy API and server-key authentication are retired.
- Can I send FCM notifications to topics or conditions with this package?
- Yes, the channel is designed for device tokens, topics, and conditions through its fluent message builder. Topic subscription and token handling semantics are broadly preserved in FCM's newer APIs, but this package still sends via the retired legacy endpoint. For new work, you need an HTTP v1 implementation that rebuilds the message envelope and authentication.
- Is ankurk91/fcm-notification-channel still maintained and safe for production?
- No, the repository is archived, the last release was in February 2022, and there are no upstream fixes, security patches, or dependency updates. The larger production risk is that it calls the retired legacy FCM HTTP API with legacy server-key authentication. Only existing systems with still-valid legacy credentials can realistically use it, and those credentials have a finite shelf life.
- Does this package support the FCM HTTP v1 API and OAuth2 service accounts?
- No. It targets the legacy FCM HTTP API at fcm.googleapis.com/fcm/send and authenticates with a legacy server key, not the HTTP v1 endpoint or OAuth2 service-account tokens. It also lacks v1 error semantics, retry behavior, and project-scoped request envelopes. For HTTP v1, use a maintained package such as laravel-notification-channels/fcm v2 or kreait/laravel-firebase, or write a small first-party channel.
- How should I test this FCM channel in a Laravel application?
- Use Laravel's Notification::fake() to assert that the notification is sent through the fcm channel without hitting Firebase, and unit-test your toFcm() payload builder independently. For a real-device smoke test, you need a legacy FCM project with a valid server key, which is increasingly difficult to stand up. Validate current delivery against a real device in the last 30 days before relying on it.
- What are the best alternatives to this package for Laravel FCM push notifications?
- For maintained HTTP v1 support, evaluate laravel-notification-channels/fcm v2 or kreait/laravel-firebase. A small first-party channel over the FCM HTTP v1 endpoint with a service account is also a durable option and avoids adopting an archived dependency. Define an internal PushSender interface so you can swap implementations without changing notification call sites.
- How do I migrate away from this package to FCM HTTP v1 without breaking call sites?
- Introduce an application-level PushSender interface, implement it behind the current package first, and then replace that implementation with an HTTP v1 sender using service-account credentials. The v1 API changes the project-scoped URL, message wrapper, token targeting, and authentication model, so re-verify the payload shape during migration. Keep device token and topic subscription handling stable at the application layer so notification classes do not depend on the vendor package's lifecycle.