Feature Overview
API Access

API Access & Keys

RealTimeX exposes a developer API for scripts, backend services, automations, custom apps, and advanced integrations.

You manage access from Settings > API Keys.

What API keys do

An API key gives programmatic access to your RealTimeX instance. In practice, that means external clients can use it to call supported endpoints for things like:

  • workspaces and threads
  • document ingestion and retrieval
  • system and admin automation
  • embed management
  • OpenAI-compatible chat and embeddings

Treat an API key like a password. Anyone who has it can act against your instance with the permissions that API surface allows.

Open the live API reference

Your instance hosts its own interactive API reference at /api/docs.

That page is the best place to check:

  • exact paths and request bodies
  • response formats
  • required headers
  • which endpoints belong to the standard API, OpenAI-compatible API, or SDK surfaces

Use the docs on your own instance, not just docs.realtimex.ai, when you need request-level detail.

Create and manage keys

Open Settings > API Keys to manage access.

The current product flow lets you:

  • generate a new API key
  • copy an existing key
  • review who created the key
  • review when the key was created
  • deactivate old keys you no longer want to trust

The settings page also links directly to /api/docs, so you can move from key management to endpoint testing without leaving the product.

In multi-user setups, API keys are typically managed by admins. In single-user or system-managed setups, the system operator manages them.

Use the right auth header

RealTimeX has more than one API surface, so the expected auth header can vary by route.

In the current app:

  • many standard API and OpenAI-compatible requests use Authorization: Bearer <YOUR_API_KEY>
  • some SDK-oriented routes document x-api-key
  • registered local app flows can use x-app-id instead of a user-generated API key

If you are calling a route from /api/docs, follow the auth header shown for that specific endpoint.

Main API surfaces

Standard developer API

Use the standard API when you want to manage RealTimeX resources directly.

Common areas include:

  • system information and health
  • workspaces and workspace threads
  • documents and ingestion
  • embeds
  • admin and user-management actions

OpenAI-compatible API

Use the OpenAI-compatible endpoints when you want existing OpenAI-style clients to talk to RealTimeX with minimal changes.

This surface includes endpoints for:

  • model listing
  • chat completions
  • embeddings

In this mode, workspaces act like models. That means the model value you send is typically a RealTimeX workspace slug rather than a raw provider model name.

SDK and Local App routes

Some integrations use the SDK-style routes and local-app identity model instead of a general API key.

This matters when you are working with:

  • registered local apps
  • desktop runtime integrations
  • permission-scoped app access

If you are building that kind of integration, also review Local Apps.

API keys vs Credentials

API keys and Credentials solve different problems:

  • API Keys let outside clients call into RealTimeX
  • Credentials let RealTimeX agents, plugins, or tools authenticate outward to other systems

If you are connecting a script, backend, or third-party client to RealTimeX, you usually need an API key.

If you are storing OAuth tokens, bearer tokens, API secrets, or usernames/passwords for agent use inside RealTimeX, you usually need Credentials instead.

Rotation and safety

Use a separate key per integration when possible. That makes it easier to rotate access without breaking unrelated automations.

Recommended practices:

  • do not paste API keys into public chats, tickets, or docs
  • store keys in a secret manager or environment variable
  • deactivate keys that are no longer in use
  • rotate keys after team changes or suspected exposure
  • prefer dedicated app registration flows when an integration is built around Local Apps instead of shared API keys

Deactivating a key should be treated as permanent. Update the client using that key before you remove it.