Blog Articles

chevron right

FCM

chevron right

FCM Migration Guide for APEX

blog image

FCM Migration Guide for APEX

Essential guidance for migrating from FCM Legacy to HTTP v1 in Salesforce Apex. Expert strategies for seamless transition.

FCM Migration Guide for APEX
Sahil Khurana
Published: March 7, 2024

Key takeaways

  1. Migration Benefits: Moving from FCM Legacy to HTTP v1 also adds reliability, security and offers more features at the same time. HTTP v1 used to support OAuth 2. 0 for secure communication and also has some characteristics such as the ability to batch messages.

  2. Updated Implementation: When transitioning to HTTP v1, there are some modifications like structure of payloads, shift in endpoints, and changes in the methods of authentication. Some of the known methods for proper handling of responses and errors will be discussed below.

  3. Secure Credential Storage: Storing FCM credentials in Salesforce Custom Metadata Types is safe and convenient at the same time. This helps in appealing the problem of hard-coding of sensitive information and makes security consistent across environments.

FCM, or Firebase Cloud Messaging, has always been a leading choice for reaching your users with notifications and messages regardless of the platform. Nevertheless, the technology is not limited to communication methods; instead, the methods and protocols are also moving along with the evolution of the technology. Hence, following the development, HTTP v1 is implemented instead of the IPv0 FCM. Replacing the old protocol with a new one will help us to reach higher reliability, better security, and, at the same time, include some extra functions. In this blog, we will discuss migration of legacy FCM to HTTP v1 using apex in salesforce.

Why Migrate to HTTP v1?

Migrating to HTTP v1 offers several compelling advantages:

  • Improved Reliability: HTTP v1 uses the channels with greater stable performance for reliability in delivering the messages to the FM servers that are Cloud Messaging.
  • Enhanced Security:  HTTP v1 is focusing on authentication that is using OAuth 2.0, in order to ensure secure interaction of Salesforce environment and FCM servers.
  • Support for New Features: HTTP v1 creates new features: the message batching , by using it, the transmission of multiple messages in a single data package helps expedite such processes.

Sending Push Notification using the FCM Legacy

Push notification from FCM

Currently, developers comprising the FCM Legacy team place the JSON containing the packet of necessary details, for instance, the recipient’s device ID, within the phone’s device memory. The device ID is identified through settings, under a hidden ID field. And it sends an HTTP request to the FCM endpoint (HTTP includes appropriate headers and payload) with the content above

Here’s a simplified example of how notifications might have been sent using FCM Legacy in Salesforce Apex:

push notification code FCM legacy

Migrating to HTTP v1

In order to migrate from FCM Legacy to HTTP v1, we have to perform different sets of variation to the implementation, for example payload structure adjustment, endpoints adjustment, authentication/authorization method changing and response/error handling.

HTTPV1 migration

Methods to generate JWT and Access Token

Here are the methods that you can use to generate the JWT and Access token required for the FCM HTTP V1 API:

generate JWT and access token

Comparing Changes:

Here’s a comparison of changes between FCM Legacy and HTTP v1:

FCM LegacyHTTP v1
Payload Structure{    “to”: “DEVICE_ID”,    “notification”: {        “title”: “Title”,        “body”: “Body”    }}
{    “message”: {        “token”: “DEVICE_ID”,        “notification”: {            “title”: “Title”,            “body”: “Body”        }    }}
Endpointhttps://fcm.googleapis.com/fcm/sendhttps://fcm.googleapis.com/v1/projects/YOUR_PROJECT_ID/messages:send
Authorizationkey= YOUR_LEGACY_SERVER_KEYBearer YOUR_ACCESS_TOKEN
Response{    “multicast_id”: 1591429548771005280,    “success”: 0,    “failure”: 2,    “canonical_ids”: 0,    “results”: [        {            “error”: “NotRegistered”        },        {            “error”: “NotRegistered”        }    ]}On Success:{    “name”:  “projects/[your-project-id]/messages/[messageId]”
}

On Failure:{    “error”: {        “code”: 401,        “message”: “Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.”,        “status”: “UNAUTHENTICATED”    }}

Custom Metadata for Storing Credential

Keeping your credentials private is very recommended both project id, client id in particular private key securedly. To fulfill this objective while using Salesforce, Custom Metadata Types which help to create new, descriptive types and thereby increasing the information much more. With Custom Metadata Types storage and managing the custom data can be done seamlessly without any deployment issues when working between environments.

To store the credentials in Custom Metadata:

  • 1.  Define Custom Metadata Type:
    • Go to Setup > Custom Metadata Types.
    • Let us create a new Custom Metadata Type like “FCM_Settings”.
    • Define the fields <br> <i>for <br> project ID, client ID and private <br> key</i><br>
  • 2. Store Credentials:
    • Set a new space for “FCM_Settings” that the custom metadata type will be used.
    • In the fields please fill out the website, which address it is located and the phone number it has.
  • 3. Retrieve Credentials in Code:
    • Investigate Apex to declare the Custom Metadata records and pull the credentials as necessary.

Here’s an example of how to retrieve credentials in Apex:

      FCM_Settings__mdt firebaseConfig = [
            SELECT Client_Id__c, Private_Key_HTTP_V1__c, Project_Id__c
            FROM FCM_Settings__mdt
            LIMIT 1
        ];

        String privateKey = firebaseConfig.Private_Key_HTTP_V1__c;
        String clientId = firebaseConfig.Client_Id__c;
        String projectId = firebaseConfig.Project_Id__c;

// Query Custom Metadata records

Use Custom Metadata to store the password instead of hard-coding so that any malicious person who views the code cannot access it.

Conclusion

Migrating from FCM Legacy to HTTP V1 in Salesforce Apex is crucial for utilization of the latest features, making the system more reliable and secured. Bearing this in mind, through implementation of the steps described in this blogpost and editing your code according to the requirements, you would successfully update your HTTP v1 and easily send stimulating notifications to your users with a sense of confidence. Anyway, through the use of the Custom Metadata Types to store the credentials the information is going to be securely managed within the Salesforce platform.

Get a Fast Estimate on Your Software
Development Project

Related Blog Articles

thumbnail
How Innostax Helped an Online Education Platform Modernize Its Entire Tech Stack

View Article
thumbnail
Streamlining Gladly Task Creation with Apex Code

In the realm of modern work dynamics, efficient task management is the linchpin of heightened…

View Article
thumbnail
Comprehensive Guide to Queueable Apex in Salesforce

Within the ever-evolving sphere of Salesforce development, where efficiency and scalability reign supreme, Queueable Apex…

View Article
thumbnail
Mastering Salesforce Data Governance: Best Practices Guide

In this guide, we will explore best practices for implementing Salesforce data governance. We will…

View Article
thumbnail
Comprehensive Guide to Batch Apex Classes in Salesforce

Introduction Within the dynamic landscape of Salesforce development, enhancing the processing of substantial datasets is…

View Article
thumbnail
A Deep Dive into Salesforce Automation Tools

Introduction Embarking on the ever evolving journey of contemporary business operations, Salesforce automation tools emerge…

View Article
© 2025 Innostax. All rights reserved. | Privacy
us-map

Web Development Services in the United States

  • Alabama
  • Alaska
  • Arizona
  • Arkansas
  • California
  • Colorado
  • Connecticut
  • Delaware
  • Florida
  • Georgia
  • Hawaii
  • Idaho
  • Illinois
  • Indiana
  • Iowa
  • Kansas
  • Kentucky
  • Louisiana
  • Maine
  • Maryland
  • Massachusetts
  • Michigan
  • Minnesota
  • Mississippi
  • Missouri
  • Montana
  • Nebraska
  • Nevada
  • New Hampshire
  • New Jersey
  • New Mexico
  • New York
  • North Carolina
  • North Dakota
  • Ohio
  • Oklahoma
  • Oregon
  • Pennsylvania
  • Rhode Island
  • South Carolina
  • South Dakota
  • Tennessee
  • Texas
  • Utah
  • Vermont
  • Virginia
  • Washington
  • West Virginia
  • Wisconsin
  • Wyoming