Introduction

Sending Firebase Cloud Messaging notifications from your own backend is the standard production setup. The Firebase Console is useful for manual tests, but it is not a delivery engine for transactional and event-driven notifications. A robust implementation uses FCM HTTP v1 or the Admin SDK with service-account-based authentication.

Use FCM HTTP v1 Instead of Legacy Server Keys

The old key-based endpoint still appears in older tutorials, but modern services should use HTTP v1. The key improvement is OAuth access tokens tied to IAM permissions instead of long-lived shared keys.

What you need before sending:

• a Firebase project with Cloud Messaging enabled.
• a service account with permission to send messages.
• target identifiers such as device token, topic, or condition.
• backend logic for retries and token cleanup.

The HTTP v1 endpoint format is:

https://fcm.googleapis.com/v1/projects/PROJECT_ID/messages:send

Send a Direct Notification to One Device

This request sends to a single registration token.

1ACCESS_TOKEN="ya29.your_oauth_token"
2PROJECT_ID="your-project-id"
3DEVICE_TOKEN="device_registration_token"
4
5curl -X POST \
6  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
7  -H "Content-Type: application/json; UTF-8" \
8  "https://fcm.googleapis.com/v1/projects/${PROJECT_ID}/messages:send" \
9  -d '{
10    "message": {
11      "token": "'"${DEVICE_TOKEN}"'",
12      "notification": {
13        "title": "Payment received",
14        "body": "Your invoice INV-204 was paid"
15      },
16      "data": {
17        "invoiceId": "INV-204",
18        "kind": "billing"
19      }
20    }
21  }'

notification fields are for user-visible text. data fields are app-defined key values consumed by client code.

Prefer Admin SDK for Backend Services

If your stack already runs Node, Java, Python, or Go, Admin SDK is usually easier than manual token generation.

1const admin = require("firebase-admin");
2
3admin.initializeApp({
4  credential: admin.credential.applicationDefault(),
5});
6
7async function sendOrderUpdate(token, orderId) {
8  const message = {
9    token,
10    notification: {
11      title: "Order update",
12      body: `Order ${orderId} has shipped`
13    },
14    data: {
15      orderId,
16      event: "order_shipped"
17    }
18  };
19
20  const id = await admin.messaging().send(message);
21  console.log("Sent message id:", id);
22}

This approach lets Google client libraries handle token refresh and most request formatting details.

Token Acquisition and Storage Model

Backend sending works only if you maintain fresh device tokens. Typical lifecycle:

1. mobile app obtains token from FCM SDK.
2. app sends token to your backend over authenticated API.
3. backend stores token with user and platform metadata.
4. backend removes token when FCM reports invalid or unregistered.

Without cleanup, your send pipeline fills with permanent failures over time.

Topic and Condition Messaging

For broadcasts, topic messaging avoids storing every token in one query.

1const message = {
2  topic: "release-notes",
3  notification: {
4    title: "Version 2.4",
5    body: "New features are available"
6  }
7};
8
9await admin.messaging().send(message);

Use topics for content segments. Use token targeting for user-specific events.

Condition expressions can combine topics, but keep them simple and tested because complex boolean targeting is hard to debug at scale.

Delivery Semantics and Retries

FCM send success means FCM accepted the message, not that the user saw it. Delivery can still be affected by OS restrictions, app state, and network conditions.

Backend retry guidance:

• retry transient errors with exponential backoff.
• do not retry permanent errors such as invalid token.
• attach request IDs in logs for traceability.
• enforce rate controls to prevent accidental message storms.

For high-volume systems, put notification requests on a queue and process asynchronously. This isolates user-facing APIs from messaging latency and improves resilience.

Security Practices

Do not embed service account credentials in client apps. Keep them in backend runtime only, ideally through workload identity or secret manager integration.

Also protect internal send endpoints. A notification API without auth and authorization checks can become a high-impact abuse vector.

Common Pitfalls

• Using outdated legacy API tutorials for new implementations.
• Storing service-account keys in source repositories.
• Ignoring invalid-token responses and never pruning stale records.
• Sending only console test messages and calling it production-ready.
• Treating accepted send response as guaranteed user delivery.

Summary

• Programmatic FCM sending should be backend-driven, not console-driven.
• Use HTTP v1 or Admin SDK with short-lived OAuth-based auth.
• Maintain token lifecycle to keep delivery quality high.
• Choose token, topic, or condition targeting based on message type.
• Add retries, observability, and strong access control for production reliability.