You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Question]: Handling Silent Push Notifications with a Custom FCM Service While Using OneSignal #2522
I’d like to ask about the feasibility of forwarding an FCM push notification payload to OneSignal.
In my use case, I need to implement a custom FirebaseMessagingService to handle background data processing—specifically for silent push notifications that trigger background tasks. Because of this requirement, I cannot rely solely on OneSignal’s default FCM handling.
My proposed approach is to send a high-priority FCM message to my app. When the incoming payload matches the OneSignal notification format, I would like to forward that payload to OneSignal so it can be processed and displayed as a normal OneSignal notification.
Is this approach supported or recommended, and are there any constraints or best practices I should be aware of when forwarding FCM payloads to OneSignal from a custom FCM service?
Hi! Thanks for reaching out and sharing your use case — that’s a great question.
Forwarding an FCM payload from your own FirebaseMessagingService into OneSignal is not something we currently support or recommend. The OneSignal SDK is designed to receive its notifications directly so it can properly handle notification display, analytics, opens, and internal state. Intercepting those messages and attempting to pass them along can lead to issues such as duplicate notifications, missing tracking, or the SDK not recognizing the message correctly.
The recommended approach is to let OneSignal handle user-visible notifications, and use your own FCM messages (with a distinct key or payload) for silent pushes and background processing.
If you need a custom FirebaseMessagingService, please ensure it only processes messages intended for your app logic and allows OneSignal-formatted messages to pass through untouched so the SDK can handle them as expected.
If you can share more details about the background work you need to perform or when the notification should be shown, we’re happy to help you find the best architecture for your scenario.
At the moment, our main requirement is to perform background work for app-specific logic that is not user-visible, and we want to ensure this is architected in a way that does not conflict with OneSignal’s handling of notifications.
If there are best practices or examples for:
Structuring FCM payloads so OneSignal and app-specific messages can coexist safely, or
Having a custom FirebaseMessagingService alongside OneSignal, where the service only processes app-specific FCM messages and allows OneSignal-formatted messages to pass through untouched.
Activity
jinliu9508 commentedon Jan 23, 2026
Hi! Thanks for reaching out and sharing your use case — that’s a great question.
Forwarding an FCM payload from your own FirebaseMessagingService into OneSignal is not something we currently support or recommend. The OneSignal SDK is designed to receive its notifications directly so it can properly handle notification display, analytics, opens, and internal state. Intercepting those messages and attempting to pass them along can lead to issues such as duplicate notifications, missing tracking, or the SDK not recognizing the message correctly.
The recommended approach is to let OneSignal handle user-visible notifications, and use your own FCM messages (with a distinct key or payload) for silent pushes and background processing.
If you need a custom FirebaseMessagingService, please ensure it only processes messages intended for your app logic and allows OneSignal-formatted messages to pass through untouched so the SDK can handle them as expected.
If you can share more details about the background work you need to perform or when the notification should be shown, we’re happy to help you find the best architecture for your scenario.
parlinsqe commentedon Jan 27, 2026
At the moment, our main requirement is to perform background work for app-specific logic that is not user-visible, and we want to ensure this is architected in a way that does not conflict with OneSignal’s handling of notifications.
If there are best practices or examples for:
we’d really appreciate your guidance.
parlinsqe commentedon Jan 29, 2026
Closing this as found related answer here: #1355