RealTimeX
Start For Free

RealTimeX

API Documentation

IntroductionAuthenticationBase URLHeadersError codes
Sample requestsSample responsesStatus codesAppendixChangelog

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

PieceHow it appears in docsWhat 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=10Append only when the endpoint documents them. Some list endpoints use server defaults with no query string.
JSON bodyPretty-printed objectWhitespace is ignored. Omit keys you are not changing on PATCH.
HeadersAuthorization, Content-Type, is-tenant, x-client-idSee 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 as x-client-id when is-tenant is true.
  • 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:

terminal
PATCH {baseUrl}/api/{apiVersion}/client/moderation/users/{userId}/ban

Headers

terminal
Authorization: Bearer {{accessToken}}
Content-Type: application/json
is-tenant: true
x-client-id: {{clientId}}

Body

json
{
  "banned": true
}

Chat SDK example

Report a message from the chat app using the user access token:

terminal
POST {baseUrl}/api/{apiVersion}/messages/report

Headers

terminal
Authorization: Bearer {{userAccessToken}}
Content-Type: application/json
is-tenant: true
x-client-id: {{clientId}}

Body

json
{
  "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:

json
{
  "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: true and a valid x-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.
PreviousPresigned URLsNextSample responses

On this page

OverviewRequest conventionsPlaceholders & variablesPlatform exampleChat SDK examplePartial updates (PATCH)Best practices