Notifications

Game notifications let you talk to your players: announce an event, celebrate a milestone, win back a lapsed cohort. You author a message once as a template, send it with a campaign, and players receive it on the channels you chose — the in-game inbox, email, or push.

Scope: templates and campaigns are defined per game; the inbox is per player.

Dashboard
Unity
Unreal

Notifications live under Marketing:

Templates — the reusable message: a title and body (with a locale), the channels it can go out on, and variables you fill in at send time — write the season-start announcement once with the season name as a variable, and reuse it every season.
Campaigns — an actual send: pick a template, fill its variables, choose the audience — every player, or a segment — and send now, at a scheduled time, or on a recurring cadence. A scheduled campaign can be canceled any time before it goes out.
Delivery Status — how a send went: its lifecycle from scheduled through sending to sent, with per-channel delivery counts and any failures.

Push credentials. Push is the one channel that needs setup before anything is delivered. Under Settings → Push Notifications, configure the providers you ship on — credentials are per game, stored encrypted, and write-only: they can be replaced but never read back.

Firebase Cloud Messaging (FCM) — delivers to Android and web. Paste the full contents of the Firebase service-account JSON file.
Apple Push Notification service (APNs) — delivers to iOS. Provide the .p8 signing key, its Key ID, your Team ID, and the app’s Bundle ID. Tick Use APNs sandbox for development builds; a sandbox token will not accept production credentials, or the reverse.

Until a provider shows Configured, push tokens register successfully and nothing is ever delivered on that platform. That is the most common cause of “push is broken” — the client side reports success because registration genuinely succeeded.

The inbox. Fetch the signed-in player’s notifications, show an unread badge, and mark items read one at a time or all at once.

using Flock;
using Flock.Models;
using UnityEngine;

PaginatedResponse<Notification> inbox = await FlockClient.Instance.Notification.GetInboxAsync();
NotificationSummary summary = await FlockClient.Instance.Notification.GetSummaryAsync();
Debug.Log($"{summary.UnreadCount} unread");

// Mark the newest one read, then every one.
if (inbox.Items.Length > 0)
    await FlockClient.Instance.Notification.MarkReadAsync(inbox.Items[0]);
await FlockClient.Instance.Notification.MarkAllReadAsync();

GetSummaryAsync returns the unread count plus the newest few items, so a badge and a preview cost one call. Prefer it to refetching the whole inbox on a timer — inbox reads count toward your plan’s API usage like any other SDK call.Push. How you get a device token depends on the platform, and the SDK is explicit about which half it can do for you:

iOS — RegisterThisDeviceAsync() asks the OS for notification permission and registers the resulting APNs token in one call. It requires com.unity.mobile.notifications in the project.
Android — fetch the FCM token from Firebase yourself, then pass it to RegisterDeviceTokenAsync(token). The Firebase messaging client isn’t installable over UPM, so the SDK cannot ship it as a dependency and deliberately doesn’t try.
Everywhere else (desktop, console, Editor) — both calls throw, because the push backend has no value for those platforms.

using Flock;
using UnityEngine;

// iOS: asks for permission and registers the APNs token in one call.
if (Application.platform == RuntimePlatform.IPhonePlayer)
    await FlockClient.Instance.Notification.RegisterThisDeviceAsync();

// Android: the FCM token your own Firebase messaging code received.
if (Application.platform == RuntimePlatform.Android)
    await FlockClient.Instance.Notification.RegisterDeviceTokenAsync(fcmToken);

fcmToken is the token string from Firebase. Re-register whenever the OS issues a new token. UnregisterDeviceTokenAsync removes one.Reminders your game schedules itself. Schedule a template to arrive later — “energy full in 4 hours” — and cancel it if the player comes back first.

using System;
using Flock;
using Flock.Models;

ScheduledNotification pending = await FlockClient.Instance.Notification.ScheduleAsync(
    "energy_refilled", TimeSpan.FromHours(4));

await FlockClient.Instance.Notification.CancelScheduledAsync(pending);

The first argument is the template’s name, not its ID. Pass variables to fill the template’s placeholders, channels to restrict delivery, and locale to pick a localisation. An unknown name throws FlockErrorCode.NotificationTemplateNotFound before anything is scheduled.What the player has pending. GetScheduledAsync() asks the server, so it sees reminders set before a reinstall or on the player’s other device — not just the ones this install created.

using Flock;
using Flock.Models;
using UnityEngine;

PaginatedResponse<ScheduledNotification> pending =
    await FlockClient.Instance.Notification.GetScheduledAsync();

foreach (ScheduledNotification s in pending.Items)
    Debug.Log($"{s.Id} delivers at {s.DeliverAt}");

// Cancels every pending reminder the player has, wherever it was set.
int cancelled = await FlockClient.Instance.Notification.CancelAllScheduledAsync();

Pending is the default; pass ScheduledNotificationStatuses.Delivered or .Canceled to see the others. GetPendingSchedules() remains as a synchronous, no-network fallback covering what this install scheduled — useful offline, but prefer GetScheduledAsync when you can reach the server.Scheduling is not retried after an ambiguous failure, so a network blip cannot leave a player with two of the same reminder. Cancelling is idempotent.Reading the catalog. GetTemplatesAsync() lists the templates your game can schedule and GetTemplateByNameAsync(name, locale) fetches one. Both are game-scoped rather than per-player, so unlike the rest of this provider they work signed out.Reacting to arrivals. FlockEvents.OnNotificationReceived fires once per notification the SDK hasn’t surfaced before, oldest first. It rides the fetches your game already makes and adds no traffic — there is no realtime channel and the SDK deliberately does not poll.

using Flock;
using Flock.Models;
using UnityEngine;

public class InboxBadge : MonoBehaviour
{
    private void OnEnable() => FlockEvents.OnNotificationReceived += ShowToast;
    private void OnDisable() => FlockEvents.OnNotificationReceived -= ShowToast;

    private void ShowToast(Notification notification)
    {
        Debug.Log($"New notification: {notification.Title}");
    }
}

The inbox. Fetch the signed-in player’s notifications, show an unread badge, and mark items read one at a time or all at once.

#include "FlockSubsystem.h"

FFlockNotificationProvider* Notifications = UFlockSubsystem::Get(this)->GetNotificationProvider();

Notifications->GetNotifications([](TFlockResult<FFlockNotificationPage> Page)
{
    // Page.Value.Total is the whole inbox; Page.Value.Items is this page.
});

Notifications->GetSummary([](TFlockResult<FFlockNotificationSummary> Summary)
{
    // Summary.Value.UnreadCount, plus the newest few in Summary.Value.Items.
});

// NotificationId: an item's Id from the page.
Notifications->MarkRead(NotificationId, nullptr);
Notifications->MarkAllRead(nullptr);

GetSummary returns the unread count plus the newest few items, so a badge and a preview cost one call. Prefer it to refetching the whole inbox on a timer — inbox reads count toward your plan’s API usage like any other SDK call.Inbox reads are backed by the offline cache, so a notifications screen shows the last-known messages when the network is down rather than an error. Mark-read calls are never queued offline: a read receipt replayed an hour later would mark messages the player never saw.Push. The SDK registers a device token; it does not fetch one. Get the token from your push plugin — Firebase Cloud Messaging’s On Token Received, or OneSignal — and pass the string in:

// Token: the string your push plugin hands you.
Notifications->RegisterDeviceToken(Token, [](TFlockResult<FFlockDeviceToken> Result) {});

The platform is taken from the running build. On desktop, console and in the Editor the call fails with a validation error rather than guessing a platform — a token filed under the wrong one is accepted and then never delivers. Call Flock Get Current Device Platform first to hide an “enable notifications” toggle where push cannot work. UnregisterDeviceToken removes one; re-register whenever the OS issues a new token.Where the token comes from differs by platform:

iOS — nothing extra needed. Unreal surfaces the APNs token itself and Flock speaks APNs directly, so there is no Firebase in this path. Bind FCoreDelegates::ApplicationRegisteredForRemoteNotificationsDelegate, hex-encode the bytes, and pass the string in.
Android — a Firebase-based plugin, for now. Unreal’s own Android push plugin is built on Google Cloud Messaging, which Google decommissioned in 2019.

Built-in token acquisition is planned — a one-call iOS wrapper and a first-party Android binding — so push will not require a third-party plugin. RegisterDeviceToken does not change when they land; only where the string comes from.

Reminders your game schedules itself. Schedule a template to arrive later — “energy full in 4 hours” — and cancel it if the player comes back first.

const TWeakObjectPtr<UFlockSubsystem> Flock = UFlockSubsystem::Get(this);

Flock->GetNotificationProvider()->ScheduleByTemplateName(TEXT("energy_refilled"),
    FDateTime::UtcNow() + FTimespan::FromHours(4),
    [Flock](TFlockResult<FFlockScheduledNotification> Pending)
    {
        // The player came back first: cancel it with the id the schedule returned.
        if (Pending.bSuccess && Flock.IsValid())
        {
            Flock->GetNotificationProvider()->CancelScheduled(Pending.Value.Id, nullptr);
        }
    });

The first argument is the template’s name, not its ID — the ID is resolved internally and memoized. Pass Variables to fill the template’s placeholders and Channels to restrict delivery; leave either empty and the template’s own defaults apply. An unknown name fails with a validation error before anything is scheduled.Scheduling is not retried after an ambiguous failure, so a network blip cannot leave a player with two of the same reminder. Cancelling is idempotent.What the player has pending. GetScheduled() asks the server, so it sees reminders set before a reinstall or on the player’s other device — not just the ones this install created.

Notifications->GetScheduled([](TFlockResult<FFlockScheduledNotificationPage> Pending)
{
    for (const FFlockScheduledNotification& Entry : Pending.Value.Items)
    {
        // Entry.Id is what Cancel Scheduled Notification takes.
    }
});

// Cancels every pending reminder the player has, wherever it was set.
Notifications->CancelAllScheduled([](TFlockResult<int32> Result) { /* Result.Value cancelled */ });

Pending is the default; pass FlockScheduledNotificationStatuses::Delivered or ::Canceled to see the others. In Blueprint this is Flock Get Scheduled Notifications, whose Status pin defaults to pending — feed it from the Flock Schedule Status nodes rather than typing a value, since the wire spelling is the single-l canceled.The listing is never cached: a reminder is delivered server-side with nothing to tell the client, so a stored page would report one that has already fired as still pending. It needs a network and a signed-in player.GetPendingSchedules() remains as a synchronous, no-network fallback covering what this install scheduled — useful offline, but prefer GetScheduled when you can reach the server. CancelAllScheduled falls back to it only when the server read fails; the two are never merged.In Blueprint these are Flock Get Scheduled Notifications, Flock Cancel All Scheduled Notifications and Flock Get Pending Schedules. The Status pin defaults to pending — feed it from the Flock Schedule Status nodes rather than typing a value, since the wire spelling is the single-l canceled. Get Pending Schedules is a plain callable node, not an async one: it makes no network call.

Use Flock Cancel All Scheduled Notifications rather than looping Flock Cancel Scheduled Notification over a listing. A Blueprint ForEach fires every iteration in the same frame, and each cancel rewrites the stored pending list as it completes — so parallel cancels race, and the last one to finish restores entries the others had already removed. The dedicated node walks them sequentially for exactly that reason.

Reading the catalog. GetTemplates() lists the templates your game can schedule and GetTemplateByName(Name, Locale) fetches one. Both are game-scoped rather than per-player, so unlike the rest of this provider they work signed out.Reacting to arrivals. Two events on the hub save you diffing pages yourself:

// In AMyActor's class, each handler is a UFUNCTION():
//   void HandleNotification(const FFlockNotification& Notification);
//   void HandleUnreadCount(int32 UnreadCount);
UFlockEvents* Events = UFlockSubsystem::Get(this)->GetEvents();
Events->OnNotificationReceived.AddDynamic(this, &AMyActor::HandleNotification);
Events->OnUnreadCountChanged.AddDynamic(this, &AMyActor::HandleUnreadCount);

OnNotificationReceived fires once per notification the SDK hasn’t surfaced before, oldest first. OnUnreadCountChanged fires whenever the server reports a count — an unread-count or summary fetch, or a mark-all-read. Both ride the fetches your game already makes and add no traffic: there is no realtime channel and the SDK deliberately does not poll, so “received” means first seen by a read. The first fetch after a fresh install is silent, so an existing inbox doesn’t arrive as a burst of events on launch.

Event BeginPlay runs Bind Event to On Unread Count Changed, whose Target is Flock Get Events (a node with no execution pins), bound to an Unread Changed custom event whose Unread Count is converted to text (a small conversion node) into Print String — Keep an unread badge current: bind On Unread Count Changed once, at Begin Play.

Blueprint. Every call above has a node — Flock Get Notifications, Flock Get Notification Summary, Flock Mark Notification Read, Flock Schedule Notification, Flock Register Device Token, and the rest — plus the helpers Is Read, Is Pending, Is Delivered and Is Canceled, which have no execution pins. The two events are assignable straight off Flock Get Events.

This page is about messages to players. Alerts to your own team — error spikes, build results — are Developer Alerts.

Getting Started

Concepts

Features

Reference