ReachBellDocs

Migrate from Firebase (FCM)

This migration is different from the web-push ones. You don't migrate your FCM project — you keep it. ReachBell sits on top of your existing Firebase Cloud Messaging project and sends through your credentials, so every registration token in your user database keeps working unchanged. No app update ships, no users get re-prompted, and your client SDK never knows the swap happened. The only thing that changes is the server-side code that calls FCM.

New to the general approach? Read the migration overview first. Note that Firebase is the one path where VAPID-key import and silent re-subscribe don't apply — FCM uses device registration tokens, not web-push subscriptions.

Why teams switch from raw FCM

  • Segments and audiences. FCM gives you topics and condition strings. ReachBell adds saved segments, behavioral filters, and user-property targeting on the same token pool — no schema migration.
  • Email + push in one tool. Layer transactional and campaign email on AWS SES into the same automations as your FCM pushes — trigger a push, fall back to email if it isn't opened in an hour, all built in.
  • Predictable INR billing. FCM is "free" until you're paying for the Firebase Blaze tier underneath. ReachBell bills predictably in rupees with a GST invoice — no surprise Cloud Functions overage at month end.

1. Connect your FCM project

You keep the same Firebase project. In Firebase Console → Project Settings → Service Accounts, click Generate new private key — it downloads a JSON file. Upload that JSON to ReachBell when you create the project (Project → Channels → Mobile Push).

ReachBell uses it to mint short-lived OAuth tokens against the FCM HTTP v1 API and sign each request on your behalf. The key only authorizes sends through your own project — it stays within your Google Cloud boundary.

No token re-registration, no app release. Because ReachBell sends through your existing FCM project, every device token already in your user table keeps working. There's no client-side change, so users notice nothing.

2. Replace the send-side code

Your client app stays exactly as it is — same firebase-messaging SDK on Android, iOS, and web, same VAPID key for web, same registration tokens. On the server side, swap your Firebase Admin code (or raw FCM REST calls) for a single call to ReachBell's send endpoint:

// Remove
import * as admin from "firebase-admin";
admin.initializeApp({ credential: admin.credential.cert(serviceAccount) });
 
await admin.messaging().send({
  token: user.fcmToken,
  notification: { title: "Order shipped", body: "Tracking #..." },
  android: { priority: "high" },
});
# Add — same FCM token in the payload, friendlier API
curl -X POST https://api.reachbell.com/messages \
  -H "x-api-key: rb_live_yourkey" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "push",
    "to": { "fcmToken": "<your-existing-fcm-token>" },
    "title": "Order shipped",
    "body":  "Tracking #..."
  }'

ReachBell signs and forwards to FCM under the hood, so your token formats, batching, and TTLs all stay valid. Most teams collapse a few hundred lines of Cloud Function code into a single API call. From a Node backend, use the Server SDK (@reachbell/node) instead of raw REST — it wraps the same send with typed helpers.

Sending works the moment you pass an FCM token, but loading your tokens into ReachBell unlocks segments and audience targeting. Bulk-import them with the migration endpoint — use the android / ios channel and a deviceToken (not a web-push subscription), in batches of up to 10,000:

curl -X POST https://api.reachbell.com/migration/project/proj_01HX2.../subscribers-import \
  -H "x-api-key: rb_live_yourkey" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "firebase",
    "subscribers": [
      {
        "channel": "android",
        "deviceToken": "<fcm-registration-token>",
        "externalId": "user_4827",
        "tags": ["premium", "india"],
        "country": "IN",
        "platform": "android"
      }
    ]
  }'
{ "imported": 1, "skipped": 0, "failed": 0, "errors": [] }

Use channel: "ios" for APNs device tokens. The import maps android to an FCM token type and ios to APNs, auto-tags each subscriber migrated and migrated_from_firebase, and dedupes on the token — so re-running the same file is safe. (You can also register tokens one at a time from a native app via the Subscribers API.)

4. Verify token reachability

Open ReachBell → Project → Verification → Send Test, paste a known FCM token from your user table, and fire a test push — it should arrive on the device within seconds. If it doesn't, the diagnostics tell you exactly which credential is misconfigured. Then confirm the imported count:

curl https://api.reachbell.com/migration/project/proj_01HX2.../status \
  -H "x-api-key: rb_live_yourkey"
{
  "totalActive": 95000,
  "migrated": 95000,
  "bySource": [{ "source": "firebase", "count": 95000 }]
}

What you keep

  • Your FCM project and tokens. Same Firebase project, every registration token still valid — no app update, no token refresh.
  • APNs certificates. iOS routes through the same APNs auth key (.p8) and team ID you already configured for FCM. Upload the .p8 once and ReachBell signs each request server-side. (To talk to APNs directly without FCM in the middle, upload the .p8, team ID, and bundle ID separately and ReachBell routes iOS through APNs while Android stays on FCM.)
  • Your in-app SDK. firebase-messaging on every platform stays where it is — ReachBell only replaces the server-side send code.
  • Topic subscriptions. FCM topics (/topics/all, /topics/news_en) keep routing because sends go through your FCM project. ReachBell adds real segments on top, so you can retire the "topic per language per geo" sprawl.
  • Firebase Analytics and Remote Config. Untouched — ReachBell replaces the messaging layer, not the analytics SDK. If you used Firebase In-App Messaging or FCM A/B tests, rebuild those in the automation designer and get push + email A/B testing on the same segments.

Email sale@reachbell.com for help mapping your existing send logic — there are thin Node, Python, and Go clients to drop in.

What's next?

Previous

From Webpushr