PHP
Google Cloud Messaging
GCM tutorial
web development
cloud integration

GCM with PHP Google Cloud Messaging

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Google Cloud Messaging, or GCM, was Google's earlier push-notification service before Firebase Cloud Messaging replaced it. If you are reading old PHP code that still references GCM, the important technical point is that the delivery model was server-to-Google-to-device, and the modern migration path is FCM rather than new GCM development.

How GCM Worked With a PHP Backend

A PHP application acting as the sender would collect one or more device registration IDs, build a JSON payload, and POST it to Google's messaging endpoint with the server API key in the Authorization header.

The basic flow looked like this:

  1. The mobile app registered with Google and received a registration token.
  2. The app sent that token to your PHP backend.
  3. Your backend stored the token and later used it to send a push message.
  4. GCM accepted the request and routed the notification to the target device.

In older codebases, you will usually see https://android.googleapis.com/gcm/send as the endpoint and Authorization: key=... as the authentication mechanism.

Historical PHP Example

The code below shows the style of request old GCM integrations used. This is useful for understanding legacy systems, but not for building a new one.

php
1<?php
2$apiKey = 'YOUR_GCM_SERVER_KEY';
3$registrationIds = [
4    'device-registration-token-1',
5    'device-registration-token-2'
6];
7
8$payload = [
9    'registration_ids' => $registrationIds,
10    'data' => [
11        'title' => 'Build complete',
12        'message' => 'Your report is ready.'
13    ]
14];
15
16$headers = [
17    'Authorization: key=' . $apiKey,
18    'Content-Type: application/json'
19];
20
21$ch = curl_init('https://android.googleapis.com/gcm/send');
22curl_setopt($ch, CURLOPT_POST, true);
23curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
24curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
25curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($payload));
26
27$response = curl_exec($ch);
28if ($response === false) {
29    throw new RuntimeException(curl_error($ch));
30}
31
32curl_close($ch);
33echo $response;

The response body would tell you how many messages succeeded, how many failed, and whether some registration IDs should be deleted or updated.

Token Hygiene Was the Hard Part

The HTTP call itself was straightforward. The operational work was in token management.

Tokens could become invalid when users uninstalled the app, restored backups, or re-registered on a new device. A reliable backend had to inspect failure responses and remove stale tokens. Otherwise the database would slowly fill with unusable entries and your push metrics would degrade.

This is why production messaging systems usually store metadata next to the token, such as platform, app version, last successful send time, and last known error.

What You Should Use Now

If you need push notifications from PHP today, use Firebase Cloud Messaging. The architecture is similar, but the product, endpoints, authentication model, and SDK guidance have moved on.

A simplified PHP request to FCM HTTP v1 usually goes through an OAuth 2 access token rather than a long-lived GCM server key. Even if you are only maintaining a legacy GCM code path, it is worth documenting that the sustainable fix is migration, not patching the old endpoint forever.

A Practical Migration Strategy

For legacy apps, the cleanest migration is usually staged:

  1. Identify all places in the backend that still call the GCM endpoint.
  2. Separate message-building logic from transport logic.
  3. Replace the transport layer with FCM.
  4. Keep token cleanup and retry logic, because those concerns still matter.
  5. Remove hard-coded references to old registration-ID assumptions once clients are updated.

That approach prevents notification content rules from getting mixed up with provider-specific HTTP details.

Common Pitfalls

  • Treating GCM as a current platform. It is legacy technology, and new systems should target FCM.
  • Storing device tokens without any cleanup strategy. Invalid tokens accumulate quickly in real deployments.
  • Hard-coding the server key in source control. Messaging credentials belong in secure configuration.
  • Ignoring the response body from Google. Failures and token-refresh signals are operationally important.
  • Mixing notification content generation with transport code, which makes later migration harder.

Summary

  • GCM used a PHP backend to POST JSON payloads to Google's messaging service.
  • The mechanics were simple, but token lifecycle management was essential.
  • Legacy PHP code usually used cURL plus an Authorization: key=... header.
  • The modern replacement for GCM is Firebase Cloud Messaging.
  • If you maintain old GCM code, the right long-term fix is migration, not further expansion of the legacy path.

Course illustration
Course illustration

All Rights Reserved.