How to Set Up Firebase Credentials for Push Notifications

Push notifications depend on several credentials, and confusing their roles is one of the easiest ways to create an insecure or unreliable setup. Firebase Cloud Messaging, commonly called FCM, uses application configuration on client devices and authenticated credentials on the server side. Apple devices also require an APNs connection beneath the Firebase layer.

This guide explains how to set up those credentials, where each file or key belongs, how to test the configuration, and which mistakes commonly cause authentication or delivery failures. The exact screens and labels in Google Firebase Console can change, so treat the names below as a practical model and verify current Firebase documentation before deploying.

Understand the credential layers

Before creating anything, separate the setup into three layers:

• Client configuration tells an Android, iOS, or web application which Firebase project to use.
• Server authentication lets a trusted backend request push delivery from Firebase.
• Platform credentials allow Firebase to reach the underlying delivery network, especially APNs for iOS and iPadOS.

These credentials are not interchangeable. A Firebase client configuration file is not a server secret. A service account private key should never be bundled into an app. An APNs key is not a replacement for Firebase server authentication.

You should also decide whether your application sends directly through FCM or uses a provider such as HoneyNotify. If HoneyNotify is your delivery layer, configure credentials according to its current Firebase integration documentation and keep its API authentication separate from Firebase credentials. HoneyNotify server-side sends use a POST request to /v1/notifications with a Bearer API key and an Idempotency-Key. That API key authenticates the request to HoneyNotify; it does not replace the Firebase credentials needed by a Firebase integration.

Create or select the Firebase project

Use a dedicated Firebase project for each meaningful environment, such as development, staging, and production. Separating environments reduces the risk of sending test notifications to real users and makes it easier to restrict access.

In the Firebase console:

• Create a project or select the existing project that should own push delivery.
• Record the Firebase project ID and project number.
• Decide which Android package name, iOS bundle ID, or web application belongs to the project.
• Confirm that the required messaging service is enabled for the project.

The project ID is used in server-side authentication and requests. The project number and sender identifier may appear in client configuration. Do not copy values between projects casually: a client registered against one project may not be compatible with server credentials from another.

Configure the Android application

Register the Android application in the Firebase project using its exact package name. If the application uses separate package names for development and production, register each one separately.

Download the Android Firebase configuration file, commonly named google-services.json, and place it where the Android build system expects it. The location depends on the project structure and build tooling, so follow the current Firebase Android setup instructions rather than placing the file in an arbitrary directory.

Check these points before building:

• The package name in the file matches the application identifier installed on the device.
• The file belongs to the intended Firebase project and environment.
• The Firebase messaging dependency and required Google services build configuration are present.
• Release builds use the intended configuration rather than accidentally reusing a development file.

Although google-services.json contains values that are intended to configure the client, it should still be treated as project configuration rather than casually committed without review. More importantly, never put a service account JSON file in the Android project or inside the distributed application.

After the app starts, initialise the messaging client using the supported Firebase SDK. Request notification permission where the operating system requires it, obtain the current registration token, and send that token to your backend over an authenticated connection. Tokens can change, so registration should not be a one-time operation tied only to first launch.

Configure the Apple application

Register the iOS application using its exact bundle ID. Download the relevant Firebase configuration file, commonly named GoogleService-Info.plist, and add it to the correct application target. Confirm that the file is associated with the intended build configuration.

Firebase delivery to Apple devices also depends on APNs. In the Firebase project settings, configure an APNs authentication key or certificate according to the current Firebase guidance. The APNs key belongs to the Apple Developer account and normally requires the correct team identifier, key identifier, and push notification entitlement context.

The important distinction is that Firebase does not remove Apple platform requirements. Your iOS application still needs the appropriate Push Notifications capability and remote notification background mode where required by its behaviour. It must request notification authorisation from the user, register with APNs, and pass the resulting token through the Firebase messaging SDK as required by the current SDK version.

For production, check that the APNs credential belongs to the Apple Developer team that owns the application’s bundle ID. A valid Firebase project with an incorrect APNs key can produce a setup that appears healthy on Android but fails on Apple devices.

Create secure server credentials

For server-to-server FCM access, use the current Firebase-supported authentication method, normally Google service account authentication with short-lived access tokens. In Google Cloud or Firebase project settings, create or select a service account with only the permissions required for messaging.

If you download a service account JSON key, protect it as a high-value secret:

• Store it in a secret manager or protected deployment configuration.
• Restrict access to the service or workload that sends notifications.
• Never commit it to source control, a container image, a mobile application, or client-side JavaScript.
• Rotate or revoke it when staff, systems, or environments change.
• Audit which project and service account the deployment is using.

Where the hosting platform supports workload identity or application default credentials without a downloaded private key, prefer that approach. It reduces the number of long-lived secrets that must be copied and rotated.

A server-side notification request generally needs the Firebase project identifier, a valid access token, and a target such as a registration token, topic, or other supported address. Do not confuse a device token with a Firebase project credential. Tokens identify delivery targets; credentials authorise the sender.

Connect registration to delivery

A reliable push system treats registration as an ongoing lifecycle rather than a one-off setup task. The client SDK should register the device, obtain the current token, and send the token and relevant application identity to your backend. Your backend should update the stored record when the token changes and remove or deactivate targets that Firebase reports as invalid.

If you use a notification platform between your application and Firebase, map these responsibilities carefully. The platform may manage device registration, identity, token lifecycle, payload handling, and lifecycle events, but you must verify the current integration contract. HoneyNotify client SDKs cover these areas across iOS, Android, and Web Push. Do not assume that a Firebase registration token, an imported provider subscription ID, and a HoneyNotify device ID are always the same value.

When migrating from another provider, imported OneSignal subscription IDs can remain as device IDs when matching provider tokens later register. Token rotation or a different provider environment can prevent matching, so migration should include a reconciliation plan and a way to re-register active devices.

Test safely before production

Test each platform and environment independently. A useful sequence is:

• Install a development build and confirm that it requests permission correctly.
• Record the token returned by the client SDK and verify that it reaches the intended backend.
• Send a minimal notification to one known test target.
• Test an app in the foreground, background, and terminated states.
• Confirm that invalid or expired targets are handled without retrying them forever.
• Repeat the test with the production project and release signing configuration before launch.

Keep the initial payload simple. A title, body, and target are enough for a basic notification request. Add data fields, deep links, images, or platform-specific options only after basic delivery works. This narrows the cause when a test fails.

If your backend sends through HoneyNotify, ensure each notification includes the required title, body, and target. Use an Idempotency-Key for retry-safe server-side sends, and keep HoneyNotify’s Bearer API key in server-side secret storage.

Common mistakes

Several failures recur across Firebase push implementations:

• Using a client configuration file as if it were server authentication.
• Embedding a service account private key in an application or public repository.
• Registering an Android package name or iOS bundle ID that differs from the built app.
• Mixing development and production Firebase projects.
• Configuring Firebase but not configuring APNs for Apple delivery.
• Assuming a token remains permanent after reinstall, restore, app-data deletion, or token rotation.
• Testing only while the application is open and assuming background behaviour is identical.
• Retrying authentication errors indefinitely instead of fixing the project, permission, or credential mismatch.
• Treating provider subscription IDs and current device tokens as interchangeable during migration.
• Logging complete credentials or sensitive notification data in production diagnostics.

When troubleshooting, first identify the failing layer: client registration, backend storage, server authentication, platform configuration, or delivery handling. Check the project ID, application identifier, environment, token age, and credential ownership before changing application code.

Conclusion

Setting up Firebase push credentials is mainly an exercise in keeping responsibilities separate. Client configuration belongs with the relevant application, server credentials belong in protected infrastructure, and APNs configuration remains necessary for Apple delivery. Use separate environments, refresh device registrations, test the complete lifecycle, and verify the current integration requirements for any notification provider in your stack. That approach makes failures easier to diagnose and keeps sensitive credentials out of the devices that receive notifications.