API Reference
Sample Requests
How requests are shown in this documentation, and how to turn examples into working calls.
Overview
Every endpoint page includes a ready-to-adapt sample: method, URL, headers, and (when needed) a JSON body. Samples are written for humans first — pretty-printed JSON, clear placeholders, and the same header patterns you will use in Postman or your HTTP client.
There are two common caller identities in RealtimeX. Use the right token for the module you are calling:
- Platform / client token (
accessToken) — Auth, Platform admin, Dashboard, Analytics, Settings, Custom Roles, Moderation. - Chat user token (
userAccessToken) — User, Conversation, Messages, and Uploads chat SDK flows.
Full validation rules, optional fields, and error cases live on each endpoint page under API endpoints. This reference page explains the shared request style only.
Request conventions
| Piece | How it appears in docs | What you send |
|---|---|---|
| Base URL | {baseUrl}/api/{apiVersion}/... | Substitute your environment origin and version (usually v1). |
| Path parameters | :reportId or {conversationId} | Replace with a real 24-character ObjectId from a list/get response. |
| Query parameters | ?page=1&limit=10 | Append only when the endpoint documents them. Some list endpoints use server defaults with no query string. |
| JSON body | Pretty-printed object | Whitespace is ignored. Omit keys you are not changing on PATCH. |
| Headers | Authorization, Content-Type, is-tenant, x-client-id | See Headersand each endpoint's header table for required vs optional. |
Placeholders & variables
Docs and the Postman collection use the same variable names. In Postman they appear as {{name}}; in prose we often write {name} or :name for path slots.
baseUrl,apiVersion— compose every request URL.accessToken/userAccessToken— Bearer credentials for Platform vs chat user calls.clientId— sent asx-client-idwhenis-tenantistrue.- Resource ids (
conversationId,messageId,userId,reportId, …) — copy from prior list or create responses.
Never commit real tokens or passwords into docs, screenshots, or public repos. Prefer collection secrets or environment variables.
Platform example
Ban a chat user from Platform Moderation using the client access token:
PATCH {baseUrl}/api/{apiVersion}/client/moderation/users/{userId}/banHeaders
Authorization: Bearer {{accessToken}}
Content-Type: application/json
is-tenant: true
x-client-id: {{clientId}}Body
{
"banned": true
}Chat SDK example
Report a message from the chat app using the user access token:
POST {baseUrl}/api/{apiVersion}/messages/reportHeaders
Authorization: Bearer {{userAccessToken}}
Content-Type: application/json
is-tenant: true
x-client-id: {{clientId}}Body
{
"messageId": "{{messageId}}",
"reason": "spam"
}Partial updates (PATCH)
Most update endpoints accept a partial body: send only the fields you want to change. Nested objects (for example settings attachments or calls) are typically merged so omitted sibling keys keep their previous values.
Single-field settings toggle:
{
"videoCallEnabled": false
}Prefer single-field saves from forms with independent controls — smaller payloads and clearer audit trails when something goes wrong.
Best practices
- Always send HTTPS in production and never log full Authorization headers.
- Match token type to the module (Platform vs chat user) before debugging 401/403.
- For tenant routes, send both
is-tenant: trueand a validx-client-id. - Copy ids from list responses rather than inventing ObjectIds.
- After a successful write, refetch the related list/get endpoint so UI state matches the server.