Bringing your audience into PushFire

PushFire is built to work with any product—mobile, web, or backend-driven. Your audience enters through the SDK or API, and you choose the rollout that fits your team: natural registration for new users, a gradual app update, or an optional import you run when you are ready.

There is no one-size-fits-all sync playbook on purpose. Every product has different data, timelines, and compliance needs. PushFire gives you the integration surface; how fast you populate subscribers is entirely up to you.

• Through your app or backend—SDK, REST API, or server client
• As inbound data: subscribers, devices, and tags you create or update via API calls
• Visible in the console under Audience → Subscribers once your integration runs

The console is for organizing and targeting your audience—not for bulk CSV import. That keeps the platform flexible for teams who prefer full control over their data pipeline.

Shipping something new? In most cases integration is the happy path: connect PushFire during development so subscribers are created as users sign up, open the app, and register for push.

• User signs up or logs in → your code creates or updates the subscriber
• App gets an FCM token → register the device
• Add tags that match your product logic when you are ready to segment or automate

No separate migration project—registration is part of your normal product flow.

Already have users in production? PushFire still fits. You decide whether to grow your PushFire audience over time or bring existing users in faster with tooling you own:

Gradual rollout

Release an app update with the PushFire SDK or start calling the API from your backend. Subscribers appear as people use the new version. Teams that prefer a soft launch often choose this—it needs no import script and no big-bang cutover.

Optional import (your scripts)

When you want existing users in PushFire sooner, many teams run a short script or job on their infrastructure: read from your user store, call the REST API (or Node SDK) to upsert subscribers, register devices where you have tokens, and assign tags. PushFire documents the endpoints—you control schedule, retries, and idempotency.

• Try in staging first, then verify in Subscribers
• Combine with gradual rollout if you like: import a key cohort, then let everyone else onboard natively

Both approaches are valid. Mix them if it helps your use case—we are here to support the platform, not to dictate your data migration.

Questions about which path fits your product? Reach out via Support or support@pushfire.app.

• Subscriber — externalId, name, email, phone, metadata
• Device — FCM token, platform, push enabled flag
• Tags — labels for targeting, segments, and workflow logic

Segments are computed in PushFire from tag rules—you do not upload segment membership directly.

• Flutter SDK — native iOS/Android/Web
• FlutterFlow / Dreamflow — no-code builds
• Node.js — server-side upserts
• REST API — any stack; token from Developers

See Getting Started for Developers and Integrations.

1. Create your project and add Firebase credentials for push.
2. Copy your API Token from Developers.
3. Wire your chosen integration.
4. Register a test user with a device and optional tags.
5. Check Audience → Subscribers.

Pick a tag naming strategy early—segments, broadcasts, and workflows build on tags. Create Custom tags in the console or via API before your first campaign.

Your Firebase Service Account enables push delivery. It does not load subscriber lists by itself—people and devices still come from your SDK or API integration.

Skip legacy guides that promised automatic Firebase + FlutterFlow “sync.” Use the current Flutter, FlutterFlow, Node.js, or API documentation instead.