SuprSend vs Firebase Cloud Messaging (FCM): push notifications

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.

Send the push through FCM and run everything around it

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 workflow reaches every channel

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.

Every kind of message runs from one system

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 customer account is a tenant with its own setup

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.

Users choose channels per category, admins set the defaults

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.

Digests, timezone holds and channel routing in every workflow

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.

Logs that say why a message did not arrive

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.

Build notifications in the dashboard, in your own agent, or in your codebase

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.

Short answer

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

At a glance

	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

What each actually is

FCM

Firebase 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.

SuprSend

SuprSend 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.

Where they overlap

Push to Android, iOS and the webBoth reach all three. On Android the delivery under SuprSend is FCM’s own.

Campaigns from a consoleFCM’s composer and SuprSend’s broadcasts both send now, later or on a recurring schedule, in the recipient’s timezone.

Audience targetingFCM targets Google Analytics audiences, app version, language and imported segments. SuprSend targets lists built from rules, warehouse SQL, CSV, the API or a CDP.

Messages inside the appFirebase shows campaign overlays. SuprSend keeps an inbox and shows toasts.

Agent access over MCPBoth publish an MCP server that works in Claude Code, Cursor and Windsurf.

Where FCM alone is enough

Free at any volumeCloud Messaging charges nothing per message, per device or per project, with a default quota of 600,000 messages a minute.

Direct control of the payloadPriority, a lifespan of up to four weeks, collapse keys, direct-boot delivery and iOS Live Activity updates are fields on the send request.

Topics with server-side fanoutThe app subscribes a device to a topic and one request reaches every subscriber, with conditions across topics.

A/B tests tied to Google AnalyticsComposer campaigns test variants and count a conversion event per campaign.

In-app campaign overlaysCards, modals, image messages and banners appear on any Google Analytics event, with no code per campaign.

Unity and C++ SDKsGames built on either engine receive push through FCM’s own client libraries.

A push-only productOne channel, logic your server already owns, and no preferences to honour: an orchestration layer adds a bill and little else yet.

When you need SuprSend on top

Devices stored against usersThe SuprSend SDK registers each device on the user after login, so one send reaches every device that user has. With FCM alone that table, its timestamps and its pruning job are yours.

One backend call in place of an endpoint, a table and trigger codeThe Firebase messaging library stays in the app in both setups; the SuprSend SDK sits beside it, and your server sends one event.

More ways to triggerA product event, an API call, a schedule, a broadcast to a list, or a Segment event can each start the same workflow.

Delivery answers per userSupport can look up one person and see what was sent, what FCM returned and whether it was seen, without a BigQuery query.

Retries and duplicate protectionSuprSend retries FCM server errors with exponential back-off and accepts an idempotency key, so a repeated request does not send twice.

Copy changes without an app releasePush text lives in a template with versions, rollback and translation files, edited by product or growth.

Environments and a test modeDevelopment, staging and production are on every plan, and test mode blocks real delivery while a workflow is being built.

A choice of where it runsSuprSend cloud on every plan; your VPC, on-prem or BYOC on Enterprise, with the full product and vendor support.

Who works in it

FCM

Engineers 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.

SuprSend

Engineers 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.

Feature by feature

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.

How notifications are built and changed

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

Teams and scope

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

Data model and tenancy

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

Customer engagement and marketing

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

Channels

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
Email	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

Push delivery

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++

Workflows

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

Templates and content

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

Preferences

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

In-app messages

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

Analytics and logs

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

Developer experience

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

AI, by what it can do

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

Security, compliance, support

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

Pricing and implementation

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

Putting SuprSend on top of FCM

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.

FAQ

Is SuprSend an FCM competitor?

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.

Can SuprSend use FCM?

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.

Should I use FCM directly or through SuprSend?

SuprSend

SuprSend, 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.

FCM

FCM 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.

Is SuprSend cheaper than FCM?

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.

Does FCM do multi-tenancy?

SuprSend

SuprSend 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.

FCM

FCM has no tenant object. A project holds your apps, and per-customer branding, content or defaults are logic in your own code.

Does Firebase In-App Messaging replace an in-app inbox?

SuprSend

SuprSend’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.

FCM

Firebase 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.

Where does each run, and can I self-host SuprSend?

SuprSend

SuprSend 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.

FCM

FCM runs on Google’s cloud only, and every Android push passes through it whichever tool sends it.

SuprSend vs FCM