ReachBellDocs

Migrate to ReachBell

Switching push providers sounds scary because of one fear: losing your subscriber list. With ReachBell it usually doesn't happen. Web push subscriptions are bound to a VAPID key pair and your origin, not to whichever vendor created them — so if you can bring your old keys across, every browser stays subscribed the moment our SDK loads. When the old vendor locks the keys away, a silent re-subscribe rolls your active list over on each visitor's next page view, with no permission dialog.

This page is the general playbook. For the exact steps per provider, jump to the guide that matches your current stack:

  • From OneSignal — export your VAPID keys, swap one script, verify.
  • From PushEngage — import keys if exposed, otherwise silent re-subscribe.
  • From Webpushr — keys are vendor-managed, so this one is silent re-subscribe end to end.
  • From Firebase (FCM) — keep your FCM project and tokens; only the server-side send code changes.

Why teams switch

The three things every migration guide below has in common:

  • One tool, every channel. OneSignal, PushEngage, and Webpushr are push-first; email lives in a second tool you also pay for. ReachBell ships web push, mobile push, email (on AWS SES), WhatsApp, and SMS in one dashboard against one set of segments.
  • Real automations without an upsell. Welcome series, cart recovery, and win-back journeys are included on paid plans, not gated behind a "talk to sales" call.
  • INR billing with a GST invoice. Pay in rupees via UPI, cards, or net banking and download an invoice your accountant will accept — no USD card swipe, no FX markup.

The migration path

Every web-push migration is the same three moves. The only thing that changes between providers is step 1 — whether you can carry your VAPID keys or have to re-subscribe silently.

1. Bring your subscribers across

There are two ways a browser keeps its subscription, and which one you use depends entirely on whether your old provider lets you see your VAPID keys.

Import the VAPID keys (preferred). If your old provider exposes the public/private VAPID pair, paste it into ReachBell when you create the project. Because the subscription is bound to those keys and your origin, every existing browser keeps resolving to the same push endpoint — no re-prompt, no churn, no opt-in rebuild. Import them with one call:

curl -X POST https://api.reachbell.com/migration/project/proj_01HX2.../vapid-import \
  -H "x-api-key: rb_live_yourkey" \
  -H "Content-Type: application/json" \
  -d '{
    "publicKey":  "BNc...",
    "privateKey": "tZk..."
  }'
{
  "success": true,
  "message": "VAPID keys imported. Existing subscribers registered with these keys will continue working silently."
}

Silent re-subscribe (when keys are locked vendor-side). Modern push platforms — Webpushr, and newer PushEngage accounts — treat VAPID keys as vendor-managed and never hand them out. That's fine. ReachBell's SDK detects the existing push permission on your origin, mints a fresh subscription against your new VAPID pair, and registers it in the background. Enable it on init:

ReachBell.init({
  apiKey: "rb_live_yourkey",
  silentResubscribe: true, // re-binds existing permission to your new project
});

No permission re-prompt either way. The browser already granted push for your origin, and that grant survives the provider swap. Importing keys keeps the same subscription; silent re-subscribe creates a new one — but neither shows the user a permission dialog, a banner, or any interruption.

2. Swap the SDK snippet

Delete the old provider's script tag and its service-worker file from your site root, and drop in ReachBell's loader plus reachbell-sw.js. See the JavaScript integration for the full snippet; the short version:

<script src="https://app.reachbell.com/reachbell.js" defer></script>
<script>
  window.addEventListener("DOMContentLoaded", () => {
    ReachBell.init({ apiKey: "rb_live_yourkey" });
  });
</script>

The service worker must sit at the root of your origin (https://yoursite.com/reachbell-sw.js) so its scope covers every page. This is the only code change on your site — everything else lives in the dashboard.

3. Verify the subscriber count

Open ReachBell → Project → Verification, reload your site, and watch your browser appear as an active subscriber within seconds. Then check the count programmatically:

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

For a VAPID-key import, totalActive should match your old provider's count almost immediately. For a silent re-subscribe it climbs over a week or two as visitors return — that's expected, since each browser only re-binds on its next visit. Send a test push to yourself, confirm it lands, then route real traffic.

Importing subscriber data

Carrying the VAPID keys keeps the subscriptions alive, but you'll also want the metadata — tags, external user IDs, country, browser — so your segments rebuild. Export it from your old provider as CSV (every provider has an Audience → Export), then bring it in one of two ways:

  • CSV uploader — drop the file into the dashboard's subscriber importer.
  • REST API — POST the rows to the import endpoint, 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": "onesignal",
    "subscribers": [
      {
        "channel": "web_push",
        "subscription": {
          "endpoint": "https://fcm.googleapis.com/fcm/send/...",
          "keys": { "p256dh": "BNc...", "auth": "tZk..." }
        },
        "externalId": "user_4827",
        "tags": ["premium", "india"],
        "country": "IN",
        "browser": "Chrome"
      }
    ]
  }'
{ "imported": 1, "skipped": 0, "failed": 0, "errors": [] }

Every imported subscriber is auto-tagged migrated and migrated_from_<source>, so you can segment your migrated cohort and watch the rollover. The import is idempotent — it dedupes on the subscription, so re-running the same file skips rows that already exist (skipped) instead of duplicating them.

channel picks the token type. Use web_push with a subscription object for browsers, or android / ios with a deviceToken for mobile-native tokens (the Firebase guide covers that path). The endpoint caps each request at 10,000 rows — split larger lists into multiple POSTs.

Run both in parallel during cutover

You don't have to flip everything at once. Both SDKs can coexist on the page for a week: keep the old provider's worker registered, send a test campaign through ReachBell, and confirm delivery and click-through match. Once ReachBell's count plateaus, remove the old script and delete its service-worker file from your root — browsers unregister the stale worker on their next visit.

Get migration help

Every paid plan includes free migration support. Email sale@reachbell.com with your current provider, your app/site ID, and a sample CSV export — the team handles the import, rebuilds your automations in the journey designer, and runs a verification call before you flip the SDK. Most cutovers finish in a single afternoon.

What's next?

Previous

Error codes

Next

From OneSignal