Firebase push notifications, sent from Notifly workflows.
Keep your own Firebase project. You connect it to Notifly with a service account key, register your users' device tokens, and the push steps of your Notifly workflows are delivered by Firebase Cloud Messaging to Android, iOS and web apps that use it.
Notifly adds the parts FCM leaves to your backend: one trigger for push, in-app, email, SMS and chat; token bookkeeping per user; digest, delay and throttle steps; subscriber preferences checked before each send; and an activity feed with FCM's answer for every device.
What you need from Firebase
This is the one field the dashboard asks for when you connect FCM, quoted from the create form.
| Field | Required | Stored | Notes |
|---|---|---|---|
| Service Account (entire JSON file) | Required | Encrypted at rest | A multi-line field: paste the whole file. |
- Service Account (entire JSON file). Generate a private key for a service account in your Firebase project and paste the whole file. Notifly uses its
project_id,client_emailandprivate_key.
Connect FCM in the dashboard
- Sign in at app.notifly.io, open Integration Store in the sidebar and choose Connect Provider.
- In the Connect Integration sheet, open the Push tab (or search across channels), find Firebase Cloud Messaging and choose Connect.
- Pick the environment the integration belongs to. Development and Production keep separate integrations, so you can point each at a different Firebase Cloud Messaging account or key.
- Fill in Delivery Provider Credentials with the fields in the table above, then choose Create Integration.
Register a device, then trigger a push
Tokens live on the subscriber, so the trigger only names the user: Notifly sends to every FCM token that user has registered.
// npm install @notiflyio/api@0.1.26
import { Notifly } from "@notiflyio/api";
const notifly = new Notifly({ security: { secretKey: process.env.NOTIFLY_SECRET_KEY } });
// When your app sends its FCM registration token to your backend:
await notifly.subscribers.credentials.registerToken({
subscriberId: "user_123",
providerId: "fcm",
registerSubscriberDeviceTokenRequestDto: { token: fcmRegistrationToken },
});
// Later, whenever something happens:
await notifly.trigger({
workflowId: "new-comment",
to: "user_123",
payload: { author: "Ada", excerpt: "Looks good, shipping it." },
});Prefer plain HTTP? The same trigger is POST https://api.notifly.io/v1/events/trigger with an Authorization: ApiKey header and a body of { "name", "to", "payload" }.
What reaches FCM
- A notification per token. Title and body from the push step, sent through the Firebase Admin SDK as one message per registered token.
- Notifly's message id. In the data payload as
__nvMessageId, so your app can tie a tap back to the notification. - Clean token lists. Tokens FCM rejects as unregistered or invalid are removed from the subscriber, on by default.
- No token, no call. A subscriber with no FCM token is skipped and recorded in the activity feed.
What Notifly adds on top of FCM
Workflows around the send
One trigger runs a workflow: this provider’s step can sit beside in-app, email, SMS, push and chat steps, behind digest, delay and throttle steps.
Subscriber preferences, enforced at send
Before each step runs, the subscriber’s workflow and channel preferences are checked; an opted-out step is skipped and the reason is recorded.
An in-app Inbox next to it
The same workflow can write to the Notifly Inbox, a real-time in-app feed you embed with the React component or the JavaScript SDK.
Per-trigger provider parameters
Anything the trigger passes under overrides.providers.<provider id> is merged into the request Notifly sends to the provider, per workflow or per step.
Activity you can debug
Every message gets execution details in the activity feed, including the response or error the provider returned.
Secrets encrypted at rest
API keys, tokens and service accounts are stored encrypted with AES-256; new and re-saved credentials use authenticated AES-256-GCM. The table above marks which of this provider’s fields that covers.
Go deeper in the docs
Frequently asked questions
What goes in the Service Account field?
The entire JSON key file of a Firebase service account, pasted as is. Notifly reads project_id, client_email and private_key from it to start the Firebase Admin SDK for your project, and refuses a value that is not valid JSON with an error saying so. The field is stored encrypted at rest.
How do device tokens reach Notifly?
Your backend registers each token on the subscriber with subscribers.credentials.registerToken and provider id fcm. Registering the same token twice is a no-op, passing previousToken swaps a rotated token in one call, and when a subscriber goes over the token limit the oldest tokens are dropped. removeToken deletes exactly one token and leaves the others alone.
What happens to tokens FCM says are no longer valid?
When FCM rejects a token with an error such as NotRegistered, InvalidRegistration, Requested entity was not found or The registration token is not a valid FCM registration token, Notifly removes that token from the subscriber. This is on by default, so uninstalled apps stop costing you sends without a cleanup job.
Does each device get its own push?
Yes. Notifly sends one FCM message per registered token and records each one in the activity feed with the token it went to, so one dead token does not hide that the user's other device received the push. The step fails only when FCM accepted none of them.
Can my app tell which Notifly message a push came from?
Yes. Every notification Notifly sends through FCM carries the Notifly message id in its data payload under __nvMessageId, next to the title and body rendered from the push step.
Bring your provider account. Keep your sender reputation.
One POST /v1/events/trigger — email, SMS, push, in-app, and chat. 10,000 events a month, free.