ReachBellDocs

Migrate from Webpushr

Webpushr manages VAPID keys server-side and rarely exposes them to customers — that's the design pattern most modern push platforms use. So instead of importing keys, this migration runs on silent re-subscribe: ReachBell's SDK detects the existing push permission on your origin and re-binds each browser to your new project on its next visit, with no permission dialog. This guide walks the full rollover.

New to the general approach? Read the migration overview first — this guide is the Webpushr-specific version of that playbook.

Why teams switch from Webpushr

  • One tool, three channels. Webpushr is push-only. ReachBell adds email campaigns and transactional sends on AWS SES — same dashboard, same segments, one bill.
  • Real automations on paid plans. A visual journey builder with branches, waits, and exits is included; Webpushr's flows top out at sequence-style nudges.
  • INR pricing with a GST invoice. Webpushr bills in USD. ReachBell bills in rupees via UPI, cards, or net banking and issues a compliant GST invoice.

1. Configure silent re-subscribe

Webpushr treats VAPID keys as vendor-managed, so they're rarely retrievable — don't try to extract them. Set up ReachBell's silent re-subscribe mode instead: the SDK detects the existing push permission on your origin and creates a fresh subscription against your new VAPID pair, in the background. The user sees nothing.

ReachBell.init({
  apiKey: "rb_live_yourkey",
  silentResubscribe: true, // takes over the existing permission, no prompt
});

No permission re-prompt. The browser already granted push for your origin, and that grant survives the provider swap. Silent re-subscribe reuses it to register a new subscription under your keys — no dialog, no banner, no decision for the user to make. Your active list rolls into ReachBell as visitors come back to the site.

2. Replace the SDK script

Remove the cdn.webpushr.com script and the webpushr-sw.js service worker from your site root. Install ReachBell's loader plus reachbell-sw.js in their place — see the JavaScript integration for the complete walkthrough.

<!-- Remove the cdn.webpushr.com script and webpushr-sw.js -->
 
<!-- Add -->
<script src="https://app.reachbell.com/reachbell.js" defer></script>
<script>
  window.addEventListener("DOMContentLoaded", () => {
    ReachBell.init({
      apiKey: "rb_live_yourkey",
      silentResubscribe: true,
    });
  });
</script>

The push permission stays valid; only the destination changes. The service worker must live at the root of your origin (https://yoursite.com/reachbell-sw.js) so its scope covers every page — browsers re-register on the next visit.

3. Import your audience data

Silent re-subscribe restores the subscriptions; export the metadata so your segments rebuild. In Webpushr, go to Audience → Subscriber Insights → Export — you get a CSV with subscriber IDs, segment memberships, tags, browser/OS, geolocation, and last-active timestamp. Bring it in via the CSV uploader, or 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": "webpushr",
    "subscribers": [
      {
        "channel": "web_push",
        "subscription": {
          "endpoint": "https://fcm.googleapis.com/fcm/send/...",
          "keys": { "p256dh": "BNc...", "auth": "tZk..." }
        },
        "tags": ["newsletter", "india"],
        "country": "IN",
        "browser": "Chrome"
      }
    ]
  }'
{ "imported": 1, "skipped": 0, "failed": 0, "errors": [] }

Every imported subscriber is auto-tagged migrated and migrated_from_webpushr. The import dedupes on the subscription, so re-running the same file is safe, and your saved segments rebuild from the tag columns.

4. Verify the re-subscribe rollover

Open ReachBell → Project → Verification. As real visitors hit your site, you'll watch subscribers come online live. Poll the count to track the rollover:

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

Recovery depends on visit frequency. For a site with daily visitors, expect roughly 70–80% of the active list re-subscribed within one week and 90%+ within two — without a single visible prompt. Subscribers who haven't visited in 60+ days were likely dormant anyway. Send a test push, confirm it lands, then plan to retire Webpushr.

Run both in parallel during rollover

Keep both scripts on the page for a week and watch ReachBell's count climb while Webpushr's holds steady. Once ReachBell's count plateaus, remove the cdn.webpushr.com script and delete webpushr-sw.js from your root — browsers unregister the stale service worker on the next visit.

What about welcome and trigger flows?

Welcome notifications, abandoned-cart triggers, and time-zone-scheduled campaigns translate node-for-node into ReachBell's automation builder, and the team will rebuild them for you on every paid plan. Email sale@reachbell.com with your Webpushr workspace and a sample CSV — they handle the import, the flow rebuild, and a verification call. Most Webpushr cutovers complete in under three hours of engineering time.

What's next?