Skip to main content
A push reaches a device through a token, and that token belongs to a signed-in user. The Courier mobile SDKs register and refresh those tokens for you. How much they do depends on the native hook you wired up, so it is per provider, not per platform. Anything marked Manual you register yourself, and the rest of this page is how.

Hand the SDK a token

setToken is for a provider the SDK cannot fetch from, one marked Manual in the table above. You supply the string, and everything after that is still the SDK’s job. It writes to the same place the API does. setToken calls against the signed-in user, with the device record attached. There is no separate SDK store. It first deletes whichever token it last cached for that provider, so a device does not leave stale rows behind. That delete is best effort, and a failure is logged rather than thrown. Call it before anyone signs in and the token is only held on the device. signIn writes every held token to that user, and signOut deletes them again, so a shared device stops receiving the previous user’s pushes.
The device rotates its token on reinstall, on restore, and when app data is cleared. Call setToken again from that provider’s own refresh callback, or the stale one fails at the provider rather than in your code.

Manage tokens yourself

setToken still leaves the lifecycle to the SDK. To do the CRUD yourself, address the same user through one of two APIs. From a backend, or an app with no Courier SDK, use the Token Management API:
  • Store one with
  • Read what a user has with
  • Remove one on logout with
Calling all three is then your job, on every device. Nothing cleans up on sign-out, and nothing re-registers a rotated token. From inside the app, without signing anyone in, construct a CourierClient and go through its token client. It reaches the same two endpoints, authenticating with the JWT the way signIn does, and it writes nothing to Courier.shared.
The client covers writing and deleting only. Listing a user’s tokens is REST, so has no client equivalent. On Android device is required, and CourierDevice.current(context) fills it.

Read the tokens the SDK is holding

Useful when a push does not arrive and you need to confirm the device actually registered.

Notification permissions

Each SDK wraps the platform permission calls, so you prompt, read the status, and recover from a denial without touching the native APIs.
The system dialog appears once. After that only the user can change the setting, so read the status on launch and offer your own prompt into settings when it is denied.
Android has no openSettingsForApp, and Flutter names it openSettingsApp. iOS returns a UNAuthorizationStatus, Flutter and React Native return a string, and Android’s check returns a Boolean.

Control how iOS presents a foreground push

By default iOS suppresses the system banner while your app is open. Set the presentation options to change that.