Platform IM data queries
The platform console's IM data section locates records across tenants for support and authorized administration. Unlike application data in the tenant console, platform lists can be queried without selecting an application. Tenant-console access remains limited to authorized tenant data.
Default lists
Users, groups, chatrooms, calls, message review, file review, push management and callback management immediately show the latest visible records. A tenant/application selection is optional. Records sort by creation time descending, then ID descending. The default page size is 20, with 10/20/50/100 options.
Latest means the result at query time, not a live subscription. Use Refresh to fetch again. Deleted applications are excluded; resources such as deleted users and push credentials also have resource-specific exclusions. Tenant-level files can have an empty application name.
Shared filters
- Tenant: search by name or partial
org_name, or enter the complete tenant identifier. - Application: select a tenant first, then search application display names or
app_name. More candidates can be loaded. - Resource fields: enter an ID/keyword and choose available status/type filters. Calls additionally support a participant username.
- Select Query. Changing tenant clears the previous application. Clear filters to return to cross-application latest records.
- Conditions are retained in the URL for reloads and navigation. A changed filter starts at the first page rather than continuing an old cursor.
Filters intersect. Tenant, application, active status and a group-name fragment must all match when supplied together. IDs match exactly; names use literal substring matching. % and _ are not wildcards. Messages and calls do not have a name search: use their IDs. This is not full-text message-body search.
Eight resources and permissions
| Page | Typical filters and returned information | Minimum role |
|---|---|---|
| IM users | User ID/name fragment, status, creation source; nickname, disabling party, last login | viewer |
| Groups | ID/name fragment, type, status | viewer |
| Chatrooms | ID/name fragment, creation source, status | viewer |
| Calls | Call ID, audio/video, status, participant username | viewer |
| Message review | Message ID, type, active/recalled/erased status | reviewer |
| File review | File ID/name fragment, type, status | reviewer |
| Push management | Credential ID/name fragment, channel, status | viewer |
| Callback management | Endpoint-record ID/name fragment, status | viewer |
Tables show tenant, application, resource identifier, available name/type/status, creation time and a detail action. reviewer, operator and finance are not interchangeable role names; actual platform role rules apply. A super_admin has management access.
Details and administrative actions
Select a name, ID or detail action to open the record in its application scope. Lists expose only locating metadata: no message bodies, file download URLs, push secrets or callback credentials.
Content inspection, file resolution/download, evidence access, disabling and deletion retain the original business API's permission, reason, audit and reauthentication requirements. Seeing metadata does not grant every content or write permission. Complete required platform reauthentication and return to the action; refreshing login is not a substitute.
If a record is listed but its details cannot be opened, check roles, deletion, whether media is enabled, and the specific action permissions. A permission failure is not an empty result.
APIs and pagination
These APIs use platform login identity, not an application's App Token. All paths start with /platform/v1/im-data/:
| Resources | Suffixes |
|---|---|
| Users, groups, chatrooms, calls | users, groups, chatrooms, calls |
| Messages, files, push, callbacks | messages, files, push, callbacks |
Shared query parameters are org, app, keyword, status, type, limit and cursor; calls also accept username. Filters are optional. limit ranges from 1 to 100, default 20. Responses contain {items, next_cursor}. Common fields are id, name, type, status, org_name, app_name, created_at; users additionally include nickname, disabled_by, last_login_at.
Cursors bind the resource and filters. Reusing a cursor after a filter change causes an argument error; clear it and query again. File lists are registered only when media is enabled. These endpoints do not bypass content inspection restrictions.
Troubleshooting
| Symptom | Check first |
|---|---|
| No application candidates | Select tenant first, check the name/identifier, load further candidates |
| Empty results | Check retained status/type/keyword filters and deleted resources |
| Recently updated old record is not first | Sorting uses creation time, not modification time; locate by ID or other filters |
| Invalid cursor on next page | Check whether resource or filters changed |
| List visible but content unavailable | Check content-review permission, action reason and reauthentication |
For tenant-owned application operations, see Application data management.