Managing Assets
JS SDK comes with configurable options that enables developers to switch the working environment easily.
While downloading the SDK, imi-environments.js file comes pre configured with ‘default’ environment. The ‘default’ environment is based upon your setup at the platform.
This file can host multiple environments in JSON format.
var imiEnvironments = {
target: "default",
default:
{
"asset": {
"appId": '< your App ID here>',
"appSecret": '< your secret here>',
"pathConfig": {
"assetPath": "/assets/",
"root": "/"
}
},
"imiclient": {
"shouldRequestNotificationPermission": true
},
| Parameters | Description |
|---|---|
| target | Specifies the current target environment for JS SDK. The environments are defined locally within the same file. |
| pathConfig | If the website is hosted within a sub-folder, use pathConfig parameter to specify folders: //Example var pathConfig = { "assets": "/website_root/assets/", "root": "/ website_root/" } |
| pathConfig.assets | Folder ‘assets’ is the relative path to JS SDK including ‘manifest’ folder. By default, this location is derived as window.location.origin + '/assets'; //Sample Code: "assets": "/website_root/assets/", |
| pathConfig.root | Folder containing ‘sw.j’s file. Important! ‘sw.js’ file should always be in website root for Push notifications to work properly. |
| shouldRequestNotificationPermission | If true, will enable SDK to call requestPushPermission when register() API is called. If false, SDK will not request push permission when register() API is called. Developer needs to explicitly call SDK’s requestPushPermission() API on user interaction. |
Multiple Environments For Multi-App
The imi-environments.js file can host multiple app configurations. For multi-app usage, define one environment per app and pass the desired environment to startup():
var imiEnvironments = {
target: "APP_A",
APP_A: {
"asset": {
"appId": "YOUR_APP_ID_A",
"appSecret": "< your App Secret A here >",
"pathConfig": { "assetPath": "/assets/", "root": "/" }
},
"imiclient": {
"authdomain": "https://auth-a.example.com",
"rtmsdomain": "wss://rtms-a.example.com",
"shouldRequestNotificationPermission": true,
"config": {
"apiKey": "...",
"projectId": "...",
"messagingSenderId": "...",
"appId": "..."
}
},
"sw": {
"config": {
"appid": "YOUR_APP_ID_A",
"serverUrl": "https://server-a.example.com"
}
}
},
APP_B: {
"asset": {
"appId": "YOUR_APP_ID_B",
"appSecret": "< your App Secret B here >",
"pathConfig": { "assetPath": "/assets/", "root": "/" }
},
"imiclient": {
"authdomain": "https://auth-b.example.com",
"rtmsdomain": "wss://rtms-b.example.com",
"shouldRequestNotificationPermission": false
},
"sw": {
"config": {
"appid": "YOUR_APP_ID_B",
"serverUrl": "https://server-b.example.com"
}
}
}
};
Usage:
// Initialize App A
IMI.IMIconnect.startup(null, imiEnvironments["APP_A"]);
// Later, switch to App B
await IMI.IMIconnect.uninit();
IMI.IMIconnect.startup(null, imiEnvironments["APP_B"]);
For single-app usage, calling
IMI.IMIconnect.startup()without parameters continues to work as before. It reads fromimiEnvironments[imiEnvironments.target].
enableAuthTokenExchange Flag
enableAuthTokenExchange Flag| Return Type | Property Name | Description |
|---|---|---|
Boolean | enableAuthTokenExchange | The SDK now supports secure authentication using a Customer JWT, with automatic exchange to a short-lived Connect access token. |
enableAuthTokenExchange
enableAuthTokenExchangeThe SDK now supports secure authentication using a Customer JWT, with automatic exchange to a short-lived Connect access token.
- When
enableAuthTokenExchange = true, the SDK automatically handles access-token storage, injection, refresh, and retry - exchanging the Customer JWT for a short-lived Connect access token and managing its full lifecycle on the caller's behalf. - When
enableAuthTokenExchange = false(the default), the SDK sends the Customer JWT directly with each request, preserving the legacy authentication behavior.
This property only takes effect when Customer JWT authentication is configured for your asset. See the JWT Authentication tutorial for details on issuing and supplying the Customer JWT.
Notes
| Aspect | Detail |
|---|---|
| Default | false - Customer JWT sent directly with each request; legacy behavior unchanged. |
| Properties key | enableAuthTokenExchange=true in WebexConnectConfig.properties. |
| Mutability | Set at SDK initialization. Runtime changes have no effect. |
Example - imi-environments.js:
var imiEnvironments = {
target: "default",
default: {
"asset": {
"appId": "YOUR_APP_ID",
"appSecret": "< your App Secret here >",
"pathConfig": { "assetPath": "/assets/", "root": "/" }
},
"imiclient": {
"authdomain": "https://your-auth-domain.com",
"rtmsdomain": "wss://your-rtms-domain.com"
},
"sw": {
"config": {
"appid": "YOUR_APP_ID",
"serverUrl": "https://your-server.com"
}
},
"enableAuthTokenExchange": true
}
};
Storage Namespacing
In v1.9.0, each app's data is automatically isolated by appId:
| Storage | Key pattern | Example |
|---|---|---|
localStorage | IMI.Core.{appId}.{key} | IMI.Core.YOUR_APP_ID_A.deviceProfile |
sessionStorage (tab ID) | {appId}._tabId | YOUR_APP_ID_A._tabId |
sessionStorage (dedup) | {appId}.transIds | YOUR_APP_ID_A.transIds |
IndexedDB | IMI.Background.{appId} | IMI.Background.YOUR_APP_ID_A |
Multiple apps on the same origin do not share state. Each app's registered user, tokens, threads, and messages are fully isolated.
Updated 24 days ago
