VS
Firebase Cloud Messaging (FCM) delivers push to Android, iOS and the web for free. SuprSend decides what is sent, on which channel and when, and sends the push through FCM. Most teams use both.
Trusted infrastructure layer behind hundreds of platforms
FCM is the delivery service behind most Android push, and SuprSend sends its Android push through it. Firebase gives developers a send API and gives marketers a console for push and in-app campaigns.
SuprSend is the notification infrastructure above it, where engineering, product and growth run transactional, product and engagement messages on nine channels.
FCM delivers the push. The SuprSend workflow decides whether a message should go, on which channel, when, and to whom, then hands the push step to FCM and moves to the next channel if the push does not get through.
The right message reaches the right user at the right time on the right channel, with none of that logic in your application code.
One send step covers push, email, SMS, WhatsApp, the in-app inbox, web push, Slack, Teams and webhooks. Adding a channel is a step in the workflow, on the same user record and log. Firebase covers push and in-app campaigns; email, SMS and chat need other vendors and your own code.
SuprSend unifies transactional, product and customer engagement messages in one system. A password reset, a comment notification and a win-back campaign share the same users, preferences and logs. FCM splits them in two: transactional push is code on your server, and campaigns are forms in the console composer.
Each tenant carries its own branding, template version, channel defaults and inbox feed, with sub-tenants nesting five levels deep, and can route through its own providers. FCM has no customer-account object: a Firebase project holds your apps, and anything that differs per customer is logic you write.
Per category, a user picks channels and a digest schedule, a tenant admin sets the defaults above them, and every send checks those choices first. A hosted page and embeddable components ship with it. FCM has topic subscriptions and the operating system’s notification switch, with no categories.
Ten comments become one digest. A message waits for morning in the user’s timezone. Routing tries the in-app inbox, then push, then email, and stops once the user engages. FCM delivers each message the moment it is sent, so batching, waiting and routing are code on your server.
Each message keeps its workflow run, rendered content, the provider’s error and the reason a send was blocked, searchable by user for 30 to 90 days. FCM reports aggregate sends, receipts and opens with up to 24 hours of delay, and per-message records need a BigQuery export.
On its own, Firebase covers push to Android, iOS and the web at no cost, topics with server-side fanout, console campaigns with Google Analytics audiences and A/B tests, and in-app banners, modals and cards.
It does not record which user owns which device, send on any other channel, hold a preference, or wait, batch or branch.
A product manager changes a workflow in the dashboard. A developer commits the same workflow as a file and ships it through a pull request.
A marketer asks Claude to build a list and send a campaign. All three are working on the same workflows, templates and logs, so nobody waits on a ticket.
The built-in agent builds, edits and debugs notifications from a description; product and growth ship without a ticket.
Connect the MCP to Claude, ChatGPT or any client and operate templates, workflows, tenants and preferences from there.
CLI and API keep workflows versioned, diffable and reviewed in pull requests; coding agents make bulk changes.
One SuprSend customer runs its marketing email end to end from Claude Code, with nobody in the dashboard.
FCM is built from two places. Developers send through the Admin SDK or the HTTP v1 API from their own server or Cloud Functions, and the Firebase MCP server lets Claude Code, Cursor, Windsurf or Gemini CLI send an FCM message.
Marketers compose push and in-app campaigns in the console, which adds AI insights on campaign results. FCM stores no templates or workflows, so there is nothing to version, review or stage.
| If this is you | Choose |
|---|---|
| Your product sends push only, from your own server, and your team is content storing device registrations and writing retries | FCM |
| You send occasional push campaigns to Google Analytics audiences from a console and want A/B tests at no cost | FCM |
| One trigger has to reach the user on push, email, SMS, WhatsApp or an in-app inbox — FCM delivering the push. | SuprSend |
| Messages need delays, digests, branches, or an email when the push goes unseen — FCM delivering the push. | SuprSend |
| Users should choose which notifications they get and on which channel — FCM delivering the push. | SuprSend |
| Each customer account needs its own branding, content and defaults — FCM delivering the push. | SuprSend |
| Product and growth should change notification content and logic without an app release or a ticket — FCM delivering the push. | SuprSend |
| A marketing team wants its campaigns and the transactional messages in the same dashboard — FCM delivering the push. | SuprSend |
| You want agents to build, send and manage your notifications from Claude, ChatGPT, Claude Code, Cursor or Slack | SuprSend |
| FCM is already wired in and you are now writing the device table, the retry queue and the opt-out check — SuprSend taking over that code. | Both |
| SuprSend | FCM | |
|---|---|---|
| Best when | Notifications span channels and teams, with logic and preferences around each send | Push is the only channel and your server owns the logic |
| Who uses it | Engineers, product, growth, and agents over MCP | Engineers through the API; marketers in the console composer |
| Messages covered | Transactional, product and customer engagement, in one system | Push from your code; push and in-app campaigns from the console |
| Layer | Decides channel, timing, content and recipient; sends through providers | Delivers push to Android, iOS and web |
| Built and changed from | Dashboard agent, your own agent over MCP, CLI and API | Server code, console composer, Firebase MCP server |
| Channels | Email, SMS, WhatsApp, mobile push, web push, Slack, Teams, in-app inbox, webhook | Mobile push, web push, in-app overlays |
| User and device mapping | Devices registered on the user profile by the SDK | Your table of registrations, on your server |
| Workflow logic | Delay, digest, branch, routing, timezone, throttle | None; written in your code |
| Preferences | Per category and channel, digest schedule, tenant defaults | Topic subscriptions; operating system switch |
| Multi-tenancy | Nested tenants with own branding, templates, defaults | None |
| In-app | Persistent inbox with read state, plus toasts | Campaign overlays: card, modal, image, banner |
| Templates | Editors for nine channels, versions, translation files | None; strings in code or the campaign form |
| Delivery data | Per-user message log with errors and block reasons | Aggregate reports; per-message data in BigQuery |
| Campaign testing | No A/B testing | A/B testing with Google Analytics conversions |
| AI | Agents build workflows, write copy, send, and read the log | MCP server sends a message; AI insights on campaigns |
| Hosting | SuprSend cloud on every plan; your VPC, on-prem or BYOC on Enterprise | Google cloud only |
| Pricing model | Per notification per channel; 10,000 free, Essentials $100 per month | Free at any volume |
| Implementation | Days: SDK, Firebase service account as vendor, workflows in the dashboard | A day for a test push; weeks for the code around it |
| G2 | 4.8, 129 reviews | 4.5, 307 reviews, all of FCM |
FCMFirebase is Google’s app development platform, and three of its products send messages. Cloud Messaging (FCM) is the delivery service: it accepts a message from your server and carries it to Android devices over Google Play services, to iOS through APNs and to browsers through web push.
The Notifications composer sends push campaigns from the console, and In-App Messaging shows banners, modals and cards inside an open app.
Almost every Android push travels through FCM, including the ones SuprSend sends, and FCM charges nothing for it.
What surrounds delivery is yours to build: the table that maps users to devices, the logic for whether and when to send, every other channel, and preferences.
SuprSendSuprSend is notification infrastructure for products where more than one team works on notifications. An event or an API call starts a workflow, and the workflow decides the channel, the timing, the content and the recipients.
Engineers integrate once; product and growth build and change workflows, templates, lists and broadcasts from the dashboard or through an agent.
SuprSend delivers nothing to an Android device on its own. It stores each user’s device registrations, sends the push step through your Firebase project with your service account, and records what FCM returned.
Email, SMS, WhatsApp, an in-app inbox, Slack and Teams run through the same workflows, preferences and logs.
FCMEngineers write the send logic against the Admin SDK or the HTTP v1 API, host it on their server or Cloud Functions, and keep the table of device registrations. Marketers and product managers compose push and in-app campaigns in the console, target Google Analytics audiences and run A/B tests. They cannot touch anything the API sends.
Agents connect to the Firebase MCP server from Claude Code, Cursor, Windsurf or Gemini CLI and can send an FCM message to a device or a topic.
SuprSendEngineers integrate once through the API, a backend SDK in Python, Node, Java or Go, the CLI and MCP, and keep workflows and templates in the repo. Product and growth build workflows, lists, content and broadcasts in the dashboard, or have the built-in agent build them, with versions to roll back and a test mode.
Agents connect over MCP from Claude, ChatGPT, Claude Code or Cursor and create users, set preferences, write templates, trigger a notification, run a broadcast and read the delivery log.
From both products, documentation sites and pricing pages, September 2026. Plan names mark the lowest SuprSend plan that includes a feature; everything in the FCM column is free.
In SuprSend a notification is a workflow and a set of templates, each with an API and a file form behind the dashboard, so it can be edited by a person, scripted, versioned and staged.
In FCM a transactional push is a request your server builds, and a campaign is a form in the console. There is no stored object to edit, version or promote.
| Capability | SuprSend | FCM |
|---|---|---|
| Visual workflow builder | YES | NOSend logic is code on your server |
| Campaign composer in a console | YESBroadcast to a list on any channel | YESNotifications composer for push; a second composer for in-app campaigns |
| Workflows and templates managed by API | YES | NONo workflow or template objects exist |
| CLI push and pull of assets | YESWorkflows, templates, schemas, events, categories, translation files | NOThe Firebase CLI deploys app resources; messaging has no assets to deploy |
| Version history and rollback | YESEvery workflow and template | NO |
| Promotion from staging to production | YESBy CLI, from CI | NONothing to promote; each Firebase project is configured by hand |
| MCP server for agents | YESOperates users, tenants, preferences, workflows and templates | YES, BUTFirebase MCP server sends an FCM message; messaging has nothing else to operate |
| Headless UI components | YESInbox, preference centre, template editor | NO |
SuprSend is worked in by engineers, product and growth, with separate environments and a test mode between them and real users.
FCM splits by role: engineers own everything sent through the API, and anyone with console access can send a campaign to production devices.
| Capability | SuprSend | FCM |
|---|---|---|
| Who builds send logic | Engineers, product and growth, in the dashboard, by CLI or through an agent | Engineers, in server code or Cloud Functions |
| Who sends campaigns | Product, growth and marketing, from the dashboard, the API or an agent | Anyone with console access, in the composer |
| Transactional notifications | YESEvery channel | YES, BUTPush only, from your own code |
| Customer engagement campaigns | YESEvery plan, every channel | YES, BUTPush and in-app overlays only |
| One system across both | YESSame workflows, preferences and logs | NOAPI sends and composer campaigns share no content, audience or opt-out |
| Environments | YESDevelopment, staging and production on every plan | PARTIALOne Firebase project per environment, created and wired by you |
| Test mode that blocks real delivery | YESIn development and staging | PARTIALvalidate_only checks a single request without sending it |
| Roles and permissions | YES, BUTRBAC on Enterprise | YESGoogle Cloud IAM roles on the project |
SuprSend starts from a user: one profile holds every channel address, every device and any properties, and tenants sit above users.
Firebase Cloud Messaging starts from an app installation. It does not know which person owns a device, so that mapping, and anything per customer, lives in your database.
| Capability | SuprSend | FCM |
|---|---|---|
| User profile | YESOne user, every channel address, any JSON properties | NOFCM knows app installations; users live in your database |
| Devices stored against the user | YESThe SDK registers each device after the user is identified | NOYou store each registration with a timestamp on your server |
| Registration identifier | FCM registration token, set by the SuprSend SDK | Firebase Installation ID; registration tokens are deprecated and still supported |
| Stale registration clean-up | Failed sends are logged per user with FCM's error | Your job: remove on UNREGISTERED, prune after a month of inactivity; Android registrations expire after 270 days |
| Lists and audiences | Rules on properties and events, warehouse SQL, CSV, API, CDP sync | Topics, Google Analytics audiences, imported segments |
| Non-user recipients | YES, BUTObjects with their own channels and subscribers; Business | NO |
| Tenants | YES, BUTNested five levels; Business add-on, Enterprise | NOA Firebase project holds apps; it has no customer-account object |
| Per-tenant branding, templates and defaults | YES, BUTBusiness add-on, Enterprise | NOPer-customer content is logic you write |
Both send campaigns from a console. Firebase’s composer targets Google Analytics audiences and sends push or an in-app overlay. SuprSend broadcasts to a list on any channel through the workflow engine.
A marketing team working in the SuprSend dashboard also runs the event-driven transactional messages, such as password resets, invoices and alerts, from the same workflows, lists and logs as its campaigns.
| Capability | SuprSend | FCM |
|---|---|---|
| How an audience is built | Segmentation rules, scheduled warehouse SQL, CSV, API, Segment, Mixpanel, Amplitude | Analytics audiences, user properties, app version, language, topics, imported segments |
| Audience refreshes on its own | YES, BUTDynamic lists: add-on on Essentials and Business, Enterprise | YESAnalytics audiences update as users qualify |
| User properties | Any number per user, any JSON value, no schema to declare | Google Analytics user properties, registered in the console |
| Campaign channels | All nine, one or several per send | Push; in-app overlays |
| Scheduling | One-time, scheduled, recurring; recipient's timezone from Essentials | Now, scheduled, recurring; recipient's timezone |
| Campaign runs through a workflow | YESCan batch, route across channels and respect preferences | NOA campaign is one message to one audience |
| Transactional messages from the same dashboard | YES | NOTransactional push is server code |
| A/B testing of campaigns | NO | YESFirebase A/B Testing on push and in-app campaigns |
| Conversion tracking | PARTIALDelivered, seen and clicked per broadcast | YESA conversion event per campaign, from Google Analytics |
FCM is a push service with an in-app overlay product beside it. SuprSend covers nine channels from one workflow and uses FCM for one of them.
iOS push goes from SuprSend straight to APNs, and web push uses your own VAPID keys.
| Capability | SuprSend | FCM |
|---|---|---|
| Android push | YESThrough your Firebase project; Xiaomi push also supported | YES |
| iOS push | YESDirect to APNs | YESHanded to APNs |
| Web push | YESNative, with your VAPID keys | YES |
| YESThrough your email provider | NO | |
| SMS and WhatsApp | YESThrough your providers or the WhatsApp Cloud API | NO |
| Slack and MS Teams | YES | NO |
| In-app inbox | YES | NOIn-App Messaging shows overlays and keeps no feed |
| Webhook | YES | NO |
| Fallback to another channel | YESSmart channel routing stops once the user engages | NO |
On Android the delivery is FCM’s in both setups, so throughput and device limits are the same. FCM gives direct control of the payload.
SuprSend adds retries, a user-level log and the workflow around the send, and exposes fewer payload fields.
| Capability | SuprSend | FCM |
|---|---|---|
| Throughput | Bounded by your Firebase project's quota | 600,000 messages a minute by default; increases on request |
| Per-device limits | FCM's limits apply | 240 a minute and 5,000 an hour to one Android device; collapsible bursts of 20 |
| Priority and time to live | NONo priority or TTL field on the Android template | YESNormal or high priority; lifespan up to four weeks |
| Silent and data messages | YESSilent option and custom key-value pairs | YESData messages up to 4096 bytes |
| Topics with server-side fanout | NOLists and broadcasts fan out inside SuprSend | YESDevices subscribe in the app; one request reaches all |
| Retries on provider errors | YESExponential back-off on FCM server errors | NOYour server retries and honours retry-after |
| iOS Live Activity updates | NO | YES |
| Image in the notification | YES | YES |
| Client SDK platforms | Android, iOS, React Native, Flutter, web | Android, iOS, web, Flutter, Unity, C++ |
A workflow is the logic between a trigger and a send: wait, batch, branch, pick a channel, stop. SuprSend has it as a product.
FCM delivers each message the moment your server asks, so every row below is code you write and host.
| Capability | SuprSend | FCM |
|---|---|---|
| Multi-step workflows | YES | NO |
| Delay and wait for an event | YES | NO |
| Batching and digest | YES, BUTBusiness | NO |
| Branches and conditions | YESEvery plan | NO |
| Send in the recipient's timezone | YES, BUTEssentials | YES, BUTComposer campaigns only |
| Throttle per user | YES, BUTEssentials | PARTIALPer-device frequency limit on in-app campaigns |
| Fetch from an API, call a webhook | YES, BUTEssentials | NOCloud Functions can do this in code |
| Cancel a run in flight | YESBy run, recipient or workflow | PARTIALA scheduled campaign can be cancelled before its fanout starts |
SuprSend stores content as templates outside your code, with an editor per channel, variables, versions and translation files.
In FCM the title and body are strings in your request or in the campaign form, so a copy change to a transactional push is a code change.
| Capability | SuprSend | FCM |
|---|---|---|
| Content stored outside code | YES | PARTIALCampaign text in the console; API sends carry their own strings |
| Editor per channel | YESAll nine channels | PARTIALOne form for push, one for in-app layouts |
| Variables and conditional content | YESHandlebars | NOYou build the strings in code |
| Translations | YES, BUTIn the template on Essentials; translation files on Business | PARTIALLocalisation keys resolved from strings bundled in the app |
| Version history and rollback | YES | NO |
| Variants by tenant | YES, BUTMulti-tenant add-on, Enterprise | NO |
| Test send from the editor | YES | YESTest message to a device from the composer |
A preference is a user’s standing choice about what they hear and where. SuprSend stores it per category and channel and checks it before every send.
FCM has two switches: the operating system’s notification permission, and topic subscriptions your app manages.
| Capability | SuprSend | FCM |
|---|---|---|
| Preferences per category | YES, BUTBusiness | NO |
| Preferences per channel | YES, BUTBusiness | NOOne channel |
| Digest schedule chosen by the user | YES, BUTBusiness | NO |
| Tenant admin defaults above the user | YES, BUTMulti-tenant add-on, Enterprise | NO |
| Hosted page and embeddable components | YES, BUTBusiness | NO |
| Opt-out checked on every send | YESBlocked sends are logged and not billed | NOYour code checks before it calls the API |
| Topic subscribe and unsubscribe | NOLists are managed by your team | YESFrom the app or the Admin SDK |
The two in-app products do different jobs. SuprSend’s inbox is a persistent feed the user opens, with read state, fed by the same workflow as the push.
Firebase In-App Messaging shows a campaign overlay while the app is open, fetches its campaigns from the server once a day, and keeps nothing afterwards.
| Capability | SuprSend | FCM |
|---|---|---|
| Persistent feed with read state | YESEvery plan; SuprSend branding on Free | NO |
| Drop-in and headless components | YESDrop-in on web; headless on React Native, Flutter and iOS; native Android SDK | NOThe SDK renders the overlay |
| Toasts and banners | YES | YESBanner layout |
| Card, modal and image overlays | NO | YESFour layouts in the campaign composer |
| Triggered by an analytics event with no code | NO | YESAny Google Analytics event, or a programmatic trigger |
| Driven by the same workflow as push and email | YES | NO |
| Web support | YES | NOiOS, Android and Flutter |
SuprSend answers the question about one user: what was sent, what it said, and why it did not arrive.
FCM answers the question about a campaign in aggregate, and hands per-message data to BigQuery for you to query.
| Capability | SuprSend | FCM |
|---|---|---|
| Per-message log | YESSearchable by user, workflow, tenant and status | YES, BUTBigQuery export, enabled in the app and the project |
| Rendered content and provider error | YES | NOBigQuery rows carry IDs, types and timestamps |
| Reason a send was blocked | YESOpt-out, missing channel, failed condition | NO |
| Aggregate delivery funnel | YESDelivered, seen, clicked, failed | YESSends, received, impressions, opens; received and impressions on Android only |
| Data freshness | Live in the log | Reports can lag up to 24 hours |
| Retention | 30 days Free, 90 days paid | As long as you keep the BigQuery dataset |
| Export | Warehouse sync on Business; Datadog, New Relic on Enterprise | BigQuery; Data API for aggregated Android delivery |
Both are API-first. FCM’s strength is the Admin SDK and Cloud Functions next to the rest of your app backend.
SuprSend’s is everything around the send being an asset you can pull into the repo, type-check and promote.
| Capability | SuprSend | FCM |
|---|---|---|
| Backend SDKs | Python, Node, Java, Go | Admin SDK for Node, Java, Python, Go, C# |
| REST API | YES | YESHTTP v1 |
| Send from a database or auth trigger | NOTrigger by event, API, schedule or Segment | YESCloud Functions on Firestore, Auth or Analytics events |
| Payload validated against a schema | YESJSON schema per event | PARTIALvalidate_only checks one request |
| TypeScript types from schemas | YESBy CLI | NO |
| Idempotency key | YES | NODeduplication is yours |
| Status page | YES | YES |
Firebase’s AI work is aimed at building apps; for messaging it sends a message over MCP and explains campaign results.
SuprSend’s agents build and run the notifications themselves.
| Capability | SuprSend | FCM |
|---|---|---|
| Build a workflow from a description | YESSuprSend agent, in the dashboard or Slack | NO |
| Draft copy per channel | YES | NO |
| Trace why a send failed | YES | NO |
| Answer questions about results | YES | YESAI insights for messaging campaigns |
| Send a notification from a coding agent | YESOver MCP | YESOver the Firebase MCP server |
| Operate users, lists, preferences and templates from an agent | YESClaude, ChatGPT, Claude Code, Cursor, Windsurf | NO |
| SDK for your own agents | YESOpenAI, LangChain, Vercel AI | NO |
Firebase inherits Google Cloud’s identity, audit and certifications, and runs only on Google’s cloud.
SuprSend is a smaller vendor with SOC 2 Type II, a named support path and a choice of where it runs.
| Capability | SuprSend | FCM |
|---|---|---|
| Two-factor sign-in | On every plan | Google account 2-step verification |
| Single sign-on | Google and GitHub on every plan; SAML on Enterprise | Google accounts; your identity provider through Google Workspace or Cloud Identity |
| Audit trail | On Enterprise | Google Cloud audit logs, configured in the Cloud console |
| Certifications | SOC 2 Type II, GDPR; HIPAA BAA on Enterprise | ISO 27001, SOC 1, SOC 2 and SOC 3 for Cloud Messaging and In-App Messaging |
| Hosting | SuprSend cloud on every plan; your VPC, on-prem or BYOC on Enterprise, full product, supported | Google cloud only |
| Support | Slack community and chat on every plan; email on paid plans; phone and a named CSM on Enterprise | Community and the Firebase support form; paid Google Cloud support plans |
| Uptime | 99.9%; SLA on Enterprise | Not published for Cloud Messaging |
Firebase charges nothing for Cloud Messaging or In-App Messaging at any volume. SuprSend bills per notification per channel, counts a digest as one, and does not bill sends blocked by an opt-out.
With both, you pay SuprSend and FCM still delivers the push for free.
FCM bills nothing for messaging, so it is always the cheaper invoice.
SuprSend bills per notification per channel: 200,000 push notifications in a month cost $0 on FCM and $400 on SuprSend Essentials ($100 for the first 50,000, then 150 blocks of 1,000 at $2), with FCM still delivering them at no charge.
The cost on the FCM side is the engineering time for the device table, retries, preferences and every other channel. Compare on your own event-to-notification ratio; SuprSend’s pricing page and FCM’s have the detail.
| Capability | SuprSend | FCM |
|---|---|---|
| Billing unit | Notification per user per channel; digest counts as one | None; messaging is free |
| Free | 10,000 notifications a month; all channels; unlimited members | Unlimited messages on the Spark plan |
| Entry paid | Essentials $100 per month; 50,000; $2 per extra 1,000 | No paid messaging tier |
| Next tier | Business $250 per month; adds digest, preferences, objects | No paid messaging tier |
| Enterprise | Custom; volume discounts; monthly-tracked-user option | Google Cloud contract for the rest of the project |
| Other costs | Your email, SMS and WhatsApp providers | BigQuery and Cloud Functions usage on the Blaze plan |
| Time to first notification | Same day; Firebase service account added as the Android vendor | Same day for a test push; the device table and send logic follow |
Nothing leaves FCM. Your project, your service account and the messaging library in the app stay where they are, and SuprSend becomes the caller.
| FCM | SuprSend | Moves how |
|---|---|---|
| Firebase project and service account | Android push vendor | Upload the service account JSON; project stays |
| APNs key held in FCM | iOS push vendor | Add the same key; iOS sends go direct to APNs |
| Firebase messaging library in the app | Stays, with the SuprSend SDK beside it | Add the SDK; identify the user at login |
| Registration stored on your server | Push token on the user profile | SDK registers new ones; backfill by API |
| Your user-to-device table | User profile | Users API or backend SDK |
| Topic | List | Subscribers become list members |
| Send call in server code | Workflow trigger | One event or API call per product action |
| Title and body strings in code | Template with versions | Recreate in the push editor |
| Composer campaign | Broadcast to a list | Rebuild; or keep the composer for A/B tests |
| Google Analytics audience | List | CSV, API or CDP sync |
| In-App Messaging campaign | Stays in Firebase; inbox and toasts are new | Add the inbox component |
| BigQuery delivery export | Stays; SuprSend logs sit beside it | No change |
The app keeps receiving push the same way throughout, so the move can go one notification at a time.
Inventory every place your code calls FCM to send, every composer campaign, and every topic.
Set up SuprSend development and staging, and add your Firebase service account as the Android push vendor and your APNs key for iOS.
Add the SuprSend SDK to the app and identify users at login so devices register; backfill existing registrations through the API.
Rebuild the critical notifications as workflows first: security alerts, order and payment updates, mentions. Run them in test mode.
Switch those triggers from the FCM send call to a SuprSend event, one at a time, and compare the logs for a week.
Move the rest, then add what FCM could not do: a second channel, a digest, preferences, the inbox.
Enterprise customers get migration support and a scoped plan; on other plans the Slack community and docs are the path.
No. Firebase Cloud Messaging delivers push, and SuprSend sends Android push through it. The two overlap only where FCM’s console sends campaigns.
The real choice is between writing the code around FCM yourself (device table, retries, other channels, preferences, timing) and using SuprSend for it.
Yes, and for Android push it has to. You add your Firebase service account as the Android push vendor in SuprSend, keep the Firebase messaging library in the app, and SuprSend calls FCM with your credentials. Your Firebase project, quota and delivery reports stay yours.
SuprSendSuprSend, with FCM delivering, suits a product that also sends email, SMS or in-app messages, needs delays, digests or preferences, or wants product and growth to change notifications themselves.
FCMFCM directly suits a product where push is the only channel, the send logic already lives on your server, and nobody outside engineering needs to change a notification.
No. FCM messaging is free at any volume. SuprSend bills per notification per channel, with 10,000 a month free and Essentials at $100 a month for 50,000. Using both means one bill, SuprSend’s, and the saving is the engineering time you would spend building around FCM.
SuprSendSuprSend tenants carry their own branding, template versions, channel defaults and inbox feed, nest five levels deep and can route through their own providers, as a Business add-on or on Enterprise.
FCMFCM has no tenant object. A project holds your apps, and per-customer branding, content or defaults are logic in your own code.
SuprSendSuprSend’s in-app inbox is a feed the user opens, with read state, tabs and actions, on web and mobile, filled by the same workflow that sends the push and the email.
FCMFirebase In-App Messaging shows a card, modal, image or banner over the app when a Google Analytics event fires. Once dismissed it is gone, and it runs on iOS, Android and Flutter.
SuprSendSuprSend runs as SuprSend cloud on every plan. On Enterprise it also runs in your VPC, on-prem or as bring-your-own-cloud, with the full product and vendor support; see the self-hosting page.
FCMFCM runs on Google’s cloud only, and every Android push passes through it whichever tool sends it.
Join thousands of product & engineering teams using SuprSend to build and ship better notifications—faster.