To successfully send push notifications to your mobile application using MobilePush, proper provisioning on the external service side (FCM/APNs) is mandatory.
If these settings are misconfigured, notifications will fail to deliver. This article summarizes the necessary verification steps and solutions for the most common provisioning errors.
If there is a discrepancy in the provisioning settings between your application and the notification service, you may encounter the following symptoms:
Send Failure: The push notification result is Fail, accompanied by errors indicating token issues (e.g., Requested entity was not found, NotRegistered, mismatch).
Opt-In Failure (iOS): The contact status in Marketing Cloud remains Not Opted In, even though notifications are enabled on the device.
Missing Token: The System Token (Device Token) remains null or empty.
These symptoms typically indicate an authentication mismatch between the app and the PNS. Please verify your configuration against the following checklists.
Xcode Configuration:
Ensure the Push Notifications capability is enabled in your Xcode project.
Apple Developer Portal:
Verify that a valid APNs Auth Key (.p8) is created.
Note: While legacy .p12 certificates are supported, the .p8 format is recommended as it does not require annual renewal.
Marketing Cloud Administration:
Ensure the Key ID, Team ID, and Bundle ID registered in Marketing Cloud match the information in the Apple Developer Portal exactly.
[Critical] APNs Mode vs. Build Environment:
Verify that the APNs Application Mode (Sandbox / Production) in the MobilePush Administration settings matches your application's build environment.
Sandbox: Development builds (e.g., installed directly via Xcode).
Production: Release builds (e.g., TestFlight, App Store distribution).
Note: Although the .p8 key itself is valid for both environments, the APNs endpoint (mode) configured in Marketing Cloud must strictly match the app build. A mismatch will result in delivery failure.
Configuration File Placement:
Ensure the valid google-services.json file is placed in the root of the /app module directory.
Project Integrity:
Verify that the package_name and project_id inside google-services.json match your target application and Firebase project.
Marketing Cloud Administration:
Ensure the Service Account Key (JSON) uploaded to the MobilePush Administration console belongs to the same Firebase project as the google-services.json used in the app.
Note: Using a JSON file from a different Firebase project is a common cause of "Mismatch Sender ID" errors.
Firebase Setup:
firebase-messaging dependency is included in the app's dependencies.
Provisioning is primarily performed within your development environment (Android Studio, Xcode) and the respective developer consoles (Firebase/Apple).
Due to the dependency on external services, Marketing Cloud Support cannot directly verify or validate your client-side provisioning status (e.g., confirming file placement). If you contact Support, we will guide you through these verification steps or suggest isolation methods.
Review Checkpoints: Re-verify the settings listed above with your development team.
Test with the Learning App: Deploy the Salesforce Learning App (sample app). This helps isolate whether the issue lies in the specific app implementation or the configuration.
Contact Support: If the issue persists after verifying the above, providing detailed logs and error messages will help expedite the investigation.
Marketing Cloud Provisioning Info
https://help.salesforce.com/s/articleView?id=mktg.mc_mp_provisioning_info.htm&type=5
MobilePush SDK Quick Start Guide
https://developer.salesforce.com/docs/marketing/mobile-messaging-sdks/guide/prerequisites.html
Enable Push Notifications (iOS)
Provision Your App for Push with Apple
Provision Your App for Push with Google Firebase
Salesforce MobilePush Learning App
Use the Learning App to isolate issues by testing with a minimal, clean implementation.
https://developer.salesforce.com/docs/marketing/mobilepush/guide/additional-developer-resources.html
004397548

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.