Migration guide
For existing customers who need to migrate to OneSignal's new user-centric APIs and SDKs
You're Viewing User Model Documentation
OneSignal has migrated away from a device-centric model (player ID) to a new user-centric data model (OneSignal ID). To learn more, check out the User Model Migration Guide.
Please refer to Version 9 of our documentation for device-centric information.
This guide is to help you make sense of our new user model with our old player model and provide high-level guidance on migrating an existing app to User Model.
User model
We have updated our core model from a device-centric model, which requires you to manage the relationships between devices and your users. We added an optional external_id
property to Player objects, enabling you to tie those devices to a single user. Due to the complexity required to unify Players into some notion of a user, many of you couldn't take advantage of our new Journeys product, which operates on the concept of a user. Our new model, User Model, now lets you think of your users as users. Just as you'd expect 😄
You can logically think of a User as any unique person engaged with your website, service, or application. All User
entities have Identity; all instances of this type can be uniquely identified via OneSignal ID, generated upon creation, or Identity Alias.
An Identity Alias is a label and an associated identifier expressed as a key-value pair.
{
"identity": {
"ONESIGNAL_ID": "...",
"LABEL": "ASSOCIATED ID"
}
}
User objects can be identified using any Identity Alias.More details can be found here: Users. In fact, onesignal_id
is implemented as an Identity Alias with a couple of special properties:
- Read-only.
- Autogenerated by OneSignal.
- The label
onesignal_id
is reserved.
A second special-case alias exists for External ID. external_id
is implemented as an Identity Alias:
- Writeable.
- OneSignal automatically sets External ID for apps that implemented External User ID when migrating from Player Model.
- The label
external_id
is reserved.
Our Identity Alias system allows you to find your users using whichever ID you use in your system. For example, suppose you use a Facebook ID to reference users in your system; you can leverage Aliases to use that identity on OneSignal. To accomplish this, you add an Alias to your user objects setting the Alias Label to facebook and the Alias ID to the Facebook ID of your user. More details can be found here: Aliases & External ID.
User objects also contain other writeable properties inherent to a user profile, such as last active status, language, and Data Tags.
Finally, users have Subscriptions. Subscriptions represent how users engage with your website or app, whether it's push notifications via iOS, chrome, or email. Available properties on a subscription depend on the subscription type. More details can be found here: Subscriptions.
The following snippet is what a User object may look like when fetched from our API.
{
"properties": {
"tags": {
"KEY": "VALUE"
},
"country": "US",
"first_active": 1673449251,
"last_active": 1678126124
},
"identity": {
"external_id": "example123",
"onesignal_id": "ONESIGNAL_ID"
},
"subscriptions": [
{
"id": "SUBSCRIPTION_ID",
"app_id": "APP_ID",
"type": "Email",
"token": "[email protected]",
"enabled": true,
"notification_types": -99,
"session_time": 3670,
"session_count": 129,
"sdk": "",
"device_model": "",
"device_os": "",
"rooted": false,
"test_type": 0,
"app_version": "",
"net_type": 0,
"carrier": "",
"web_auth": "",
"web_p256": ""
}
]
}
Limitations
The User and Player models are incompatible, so you must update your websites and apps to our latest SDKs supporting the new User Model.
All new apps will use the User Model. It is impossible to migrate from User Model; however, migrating to User Model from the old Player Model is fine. When migrating from Player Model, OneSignal automatically merges devices by External ID (previously External User ID).
Additionally, some Integrations (User Model Supported Integrations) are not supported for this Release but will be in the future. Documentation will be updated once these items are supported.
Migration
1. Unify via External ID
You must inform us which devices belong to which users. Set the External ID with the SDK login
method or set the external_id
property through our API or CSV upload.
- Create user API
- Update user API
- Create alias (by subscription) API
- Import Email Addresses CSV
- Import Phone Numbers CSV
2. Ship an updated app and site with our latest SDKs
Our new user centric APIs and v5.x.x SDKs offer an improved user and data management experience. However, they may not be at 1:1 feature parity with our previous versions yet.
If you are migrating an existing app, we suggest using iOS and Android's Phased Rollout capabilities to ensure that there are no unexpected issues or edge cases. Here is the documentation for each:
Please review the SDKs section below for a complete list of platform versions supporting the User Model.
If you run into any challenges or have concerns, please contact our support team at [email protected]
3. Update your backend to call new User Model APIs
Review your app's backend code to ensure it doesn't call deprecated APIs. If your backed code calls any deprecated APIs, you must update those APIs to the new corresponding User Model APIs. For a complete list of deprecated APIs, see the correspondingly named section.
SDKs
Frontend SDKs now have a unified API where functionality is grouped into namespaces. Please refer to the developer references for API details:
Native
Platform | SDK | Migration Guide |
---|---|---|
Android | onesignal-android-sdk v5 | Android Native 5.0 Upgrade Guide |
iOS | onesignal-ios-sdk v5 | iOS Native 5.0 Upgrade Guide |
Web
Cross-Platform
Platform | SDK | Migration Guide |
---|---|---|
Unity | onesignal-unity-sdk v5+ OneSignal Unity Asset Store | Unity 5.0 Upgrade Guide |
Flutter | onesignal-flutter-sdk v5+ Flutter Package | Flutter 5.0 Upgrade Guide |
React Native | react-native-onesignal v5+ NPM Package | React-Native 5.0 Upgrade Guide |
Cordova, Ionic, Capacitor | onesignal-cordova-sdk v5+ NPM Package | Cordova 5.0 Upgrade Guide |
MAUI | onesignal-dotnet-sdk v5+ NuGet Gallery | .NET 5.0 Upgrade Guide |
Xamarin | Not available | .NET 5.0 Upgrade Guide |
Backend server
Platform | SDK |
---|---|
Node | onesignal-node-api v2+ |
Go | onesignal-go-api v2+ |
Java | onesignal-java-api User Model Updates Coming Soon |
.NET | onesignal-dotnet-api v2+ |
Rust | onesignal-rust-api v2+ |
Ruby | onesignal-ruby-api v2+ |
C++ | onesignal-cpp-api User Model Updates Coming Soon |
Python | onesignal-python-api v2+ |
PHP | onesignal-php-api User Model Updates Coming Soon |
Rails | onesignal-rails-plugin User Model Updates Coming Soon |
REST API
If you’re not already using one of our backend server SDKs to interact with our REST API, consider migrating to one of our many new SDKs supporting the User Model. If you cannot use one of our backend server SDKs to interact with our REST API, you must change how you call them.
Deprecated APIs
The following player model APIs have been deprecated. The table below shows which corresponding user model APIs to migrate to for similar functionality.
Deprecated Player Model APIs | New User Model APIs |
---|---|
View device | View user |
View device(s) | View user |
Add device | Create user or Create subscription |
Edit device | Update user or Update subscription |
Edit tags with External ID | Update user |
Delete player record | Delete user or Delete subscription |
New APIs
User Model brings several new APIs for managing your users and their subscriptions.
User
API | Route | Description |
---|---|---|
Create user | POST /v1/apps/{app_id}/users | Create a new user. |
View user | GET /v1/apps/{app_id}/users/by/{alias_label}/{alias_id} | View a user; includes aliases & subscriptions. |
Update user | PATCH /v1/apps/{app_id}/users/by/{alias_label}/{alias_id} | Update a user. |
Delete user | DELETE /v1/apps/{app_id}/users/by/{alias_label}/{alias_id} | Delete a user. |
View user identity | GET /v1/apps/{app_id}/users/by/{alias_label}/{alias_id}/identity | Fetch an Identity Alias. |
View user identity by subscription | GET /v1/apps/{app_id}/subscriptions/{subscription_id}/user/identity | Fetch all Identity Aliases belonging to the user with the given Subscription. |
Create alias | PATCH /v1/apps/{app_id}/users/by/{alias_label}/{alias_id}/identity | Create an Identity Alias. |
Create alias by subscription | PATCH /v1/apps/{app_id}/subscriptions/{subscription_id}/user/identity | Create an Identity Alias for the user owning the given Subscription. |
Delete alias | DELETE /v1/apps/{app_id}/users/by/{alias_label}/{alias_id}/identity/{alias_label_to_delete} | Delete an Identity Alias. |
Subscription
API | Route | Description |
---|---|---|
Create subscription | POST /v1/apps/{app_id}/users/by/{alias_label}/{alias_id}/subscriptions | Create a subscription for a given user. |
Update subscription | PATCH /v1/apps/{app_id}/subscriptions/{subscription_id} | Update an existing subscription. |
View subscription IAMs | GET /v1/apps/{app_id}/subscriptions/{subscription_id}/iams | Fetch all active in-app messages for a given subscription. |
Delete subscription | DELETE /v1/apps/{app_id}/subscriptions/{subscription_id} | Delete an existing subscription. |
Transfer subscription | PATCH /v1/apps/{app_id}/subscriptions/{subscription_id}/owner | Transfers a given subscription to another user. |
Bug Reporting
Please report any bugs or issues you encounter by opening an issue in the repository for the SDK(s) your application uses. You can also share feedback or ask questions via our Developer Community on Discord.
Known Issues
Common items to watch out for with migration.
Data Tag Migration
Users with multiple versions of your app may experience issues with mismatched tags as follows
Player Model
Tags were set at the Subscription-level (Player ID).
- Device1 (iPhone) Subscription1 | External_ID = 1 | Using SDK version 4 or less (Web SDK 15 or less) has tags set:
- Tag 1 = 1
- Tag A = A
- Device2 (Android) Subscription2 | External_ID = 1 | Using SDK version 4 or less (Web SDK 15 or less) has tags set:
- Tag 2 = 2
- Tag A = B
User Model
Tags are set at the User level, but previously set tags are still available.
Device2: Subscription2 upgrades to SDK 5 (Web SDK 16)
- Calls
OneSignal.addTags
method to set Tag 3 = 3 - Subscription2 now has tags:
- Tag 3 = 3
- Tag 2 = 2
- Tag A = B
- Device1: Subscription1 still on SDK 4
- Subscription1 now has tags:
- Tag 3 = 3
- Tag 1 = 1
- Tag A = A
- Subscription1 now has tags:
- External_ID=1 has access tags:
- Tag 3 = 3
- Tag 2 = 2
- Tag 1 = 1 (Potential problem if this tag is outdated)
- Tag A = A & B (Problem! 🙀) This user can be associated with segments and Journeys targeting Tag A = A or Tag A = B
- Current workaround:
- Create a new tag scheme for User Model. Remove old and unused tags. Update tags you wish to continue using in User Model.
- Use the Importing User Attributes or Tags CSV to update tags on all External IDs to the same value.
- Use the Update user API to update tags on all External IDs to the same value.
- Delete tags on “older” subscriptions.
- Considerations:
- Hard coded tags and users that never update but continue to use the app may continue to see mismatched tags.
- OneSignal is looking to provide other solutions. Contact [email protected] if you need assistance.
Updated about 1 month ago