Is a device token the same as a push token?

Yes, in practice. Apple calls it a device token, Firebase calls it a registration token, and many platforms just say push token. Each identifies one app installation on one device.

Do push tokens expire?

They do not have a fixed expiry, but they stop working when the app is uninstalled, the device is reset or the OS rotates the token. That is why apps re-register tokens regularly and senders drop tokens reported as invalid.

Can I move push tokens to a new provider?

Usually yes for iOS and Android, as long as the new provider uses the same APNs key and Firebase project. Web push subscriptions only move if the new provider can use the same VAPID keys. Our OneSignal alternatives guide covers what migrations look like in practice.

Back to Glossary

Mobile & Push

Push Token

A unique identifier the operating system assigns to one app on one device, which a server needs to send push notifications to that device.

Definition

A push token, also called a device token or registration token, is the address of an app installation for push notifications. On iOS, APNs issues a device token when the app registers for remote notifications. On Android, Firebase Cloud Messaging issues a registration token. In browsers, a push subscription plays the same role and contains an endpoint URL and keys. A token identifies an app on a device, not a person: one user with a phone and a tablet has two tokens, and a reinstall produces a new one.

Why It Matters

Your push audience is really a list of tokens. If tokens are not linked to the right user, pushes go to the wrong person or nobody. If invalid tokens are kept, delivery reports look worse than reality and some providers throttle you. Tokens are also what you move when you change push vendors: because APNs and FCM tokens belong to your app and credentials rather than to the vendor, you can usually import them and keep your opted-in audience without asking users again.

How It Works

At launch, the app asks the OS for a token and sends it to your backend or messaging SDK along with the platform, app version and permission state. When the user signs in, the token is linked to their user ID or email. Tokens can change after reinstalls, restores or OS updates, so apps re-register regularly. When a push service reports a token as unregistered or invalid, the sender marks it inactive. Web push subscriptions are tied to the VAPID key pair that created them, so they only keep working with the same keys.

Example

One user's devices as stored by a messaging platform:

iPhone, iOS app, APNs token a3f9...c21, permission granted, last seen today.
iPad, iOS app, APNs token 7b10...e04, permission provisional, last seen 3 days ago.
Pixel, Android app, FCM token fGx2...Qk9, permission denied, last seen 2 months ago.

A push to this user goes to the iPhone and the iPad, and the Android token stays on file in case permission is granted later.

Best Practices

1Re-register the token on every app launch and when the OS reports a change
2Link tokens to users on sign-in and unlink them on sign-out
3Store the platform, environment and permission state with each token
4Remove or deactivate tokens the push service reports as invalid
5Export your tokens before switching vendors so you can migrate without re-prompting users

Import push tokens from your current provider

Sequenzy imports iOS and Android tokens from OneSignal, Braze, Customer.io or a CSV file, keeps opted-out devices unsubscribed and matches them to contacts by external ID or email.

Learn More

Push Identifiers by Platform

Platform	Name	Issued by	Changes when
iOS	Device token	APNs	Reinstall, restore, new device
Android	Registration token	Firebase Cloud Messaging	Reinstall, app data cleared, token refresh
Web	Push subscription	The browser's push service	Site data cleared, permission revoked