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.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: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.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.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: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.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 pure helpers Is Read, Is Pending, Is Delivered and
Is Canceled. The two events are assignable straight off Flock Get Events.