Skip to main content

Migrating to v5 from v4

The only change v5 introduces is tenant scoping across the sdk.

Tenant scoping

Skip this guide if you don’t use multi-tenant architecture, i.e. if you don’t pass tenant id in userToken jwt payload and don’t use tenant id fields for preferences and in-app feed. Pass tenantId in identify and the rest of the SDK, including preferences and in-app feed, uses it. The per-call tenantId params in v4 still work and override the global one, so you can migrate gradually or leave your v4 code as is.
v5
v4
IMPORTANT: Whichever tenant you pass in sdk, it must be included in scope.tenant_id of the userToken, else the server throws scoping error. v5 also adds below methods:
  • changeTenant(tenantId) to switch the active tenant of an identified user without resetting the session. This is meant for user tokens that scope multiple tenants (scope.tenant_id as an array). Already running feed instances and previously fetched preferences keep the tenant they were initialized with — re-initialize the feed and call getPreferences again after switching. Refer docs.
  • track(event, properties, { tenantId }) to attribute a single event to a tenant. This doesn’t change the active tenant of the session.

Migrating to v4 from v3

This migration is pretty simple.
  • Pagination related meta data keys have been changed in InApp Feed.
v4
v3

Migrating to v3 from v2

This migration is pretty simple. This version also supports InApp Feed support.
  • SuprSend class export has been changed from default export to named export.
v3
v2

Migrating to v2 from v1

Migrating from v1 to v2 has breaking changes, as we have made some architectural level changes. Refer the v1 SDK documentation . Following are changes in detail:

Authentication changes

In v1, workspace key and workspace secret are used to authenticate requests made to SuprSend which is not so secure. In v2 we have changed authentication to use public API Key and Signed User Token.
v2
v1

Initializing SDK

v1 used init method to initialize SDK and suprsend instance was provided by SDK itself. In v2 we have provided SuprSend class and its clients responsibility to export the class instance and use it in other places to call library methods.
v2
v1

Synchronous methods

In v1 all methods used to be asynchronous and have returned void. In background SDK used to batch requests and make API calls. In v2 we have made all requests synchronous so you could access response of API immediately depending of status of API call. Almost all methods including preference methods return response type of API Response.
v2
v1

Renamed methods and arguments to camelCase

In v1, all library methods and method parameters are in snake_case which has been changed to camelCase in v2.
v2
v1

Removed purchase_made method

In v2 purchase_mademethod has been removed. If you are using this method in v1 you can directly call track method with event type: $purchase_made.
v2
v1

Removed set_super_properties

In v2 set_super_properties method has been removed. If you are using this method in v1 you could directly pass all these super properties as individual event properties.
After migrating please test all library methods to see if they everything is working properly. If you face any issue in migration process please reach out to us on our slack community or drop an email to us on support@suprsend.com