> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reactor.inc/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To build and serve your own model, start at /deploy/development/quickstart and /deploy/development/overview. Deploying is the default path: reactor init scaffolds a workspace, reactor auth login authenticates, and reactor model deploy registers the model, publishes the release with the weights/ folder, and activates it on Reactor's GPUs, in one command from that workspace. Docker must be running, because the publish step builds the image locally. Bump model.version in reactor.yaml before redeploying a change, because a release that already has an image is reactivated as it is. Deployment access is granted per account, so contact team@reactor.inc if a deploy is refused. Every key in reactor.yaml is documented at /deploy/platform/reactor-yaml. Model code imports reactor_runtime; Python client code imports reactor_sdk. The runtime overview explains the model interface. Running the model on your own machine with reactor run is optional and needs a GPU you attach with --gpus; /deploy/development/local-testing covers that loop and pairs a complete brightness model with a Python client test in a separate brightness-test workspace.
> Reactor hosts multiple models, each with its own connect slug (modelName) and command/event schema. The video model catalog — slug, typed SDK package, and links to its schema — is at /model-api-reference/overview. Robotics policy documentation starts at /robotics/overview; The launch policies are Cosmos Nano DROID (/robotics/cosmos/nano-policy-droid/), DreamZero DROID (/robotics/dreamzero/droid/), and FLUX Action DROID (/robotics/flux-action/droid/), organized by model family and embodiment. Some models expose one slug per experience (e.g. HappyOyster); always take the slug from the model's own pages, never guess it.
> Fastest path to a working app: `npx create-reactor-app my-app --model=<slug>` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/<model>; Python uses the base reactor-sdk package.
> Auth: exchange an API key (rk_...) for a JWT via POST https://api.reactor.inc/tokens from your server. Never put the API key in client-side code.
> Append .md to any docs URL for clean Markdown. Search these docs via the MCP server at https://docs.reactor.inc/mcp.

# Platform API Reference

> The HTTP API behind every Reactor session. Mint tokens, start sessions, negotiate transport, and manage your account, models, and deployments.

The **Reactor Platform API** is the REST (JSON-over-HTTPS) API that the SDKs and the `reactor` CLI
call for you. Call it directly when you need control from your own server. For example, you can mint
session tokens from a backend, list your account's sessions, or build your own WebRTC client.

The endpoint pages in this section are generated from the API's OpenAPI description. Each page shows
the request, every documented response, and a live playground.

## Base URL

```
https://api.reactor.inc
```

Every path in this reference is relative to that origin.

## Authentication

Most endpoints need a credential in the `Authorization` header. The API accepts two kinds:

| Credential | Looks like | Use it for |
| - | - | - |
| API key | `rk_...` | Server-to-server calls on any endpoint your key's roles allow |
| Session token | a JWT | Starting and operating sessions, from a browser or an untrusted client only |

```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
curl https://api.reactor.inc/me -H "Authorization: Bearer $REACTOR_API_KEY"
```

A few endpoints need no credential: `GET /status`, `GET /pricing`, and `GET /gpu_types`.

> [card] [Authentication](https://docs.reactor.inc/platform-api/authentication.md)
>
> Create an API key, send it, and mint session tokens limited to the models and sessions you choose.

## Versioning

The API is versioned with request headers, not URL paths.

| Header | Sent on | Purpose |
| - | - | - |
| `Reactor-API-Version` | `/tokens`, `/sessions` | The protocol version the client speaks. Currently `1`. The server echoes its own value. |
| `Reactor-API-Accept-Version` | `/tokens`, `/sessions` | Optional. The minimum server version the client needs. |
| `Reactor-WebRTC-Version` | `/sessions/{session_id}/transport/webrtc/*` | The WebRTC signaling version, as `major.minor` (for example `1.0`). |

A version older than the server supports returns `426 Upgrade Required`. A required version newer
than the server supports returns `501 Not Implemented`. A missing header is accepted.

Within a version, the API only adds things: response fields, optional request fields, enum values in
responses, error codes, and routes. Ignore response fields you do not recognize. Request bodies are
decoded strictly, so do not send fields that the reference does not list.

## Conventions

* Request and response bodies are JSON, unless a page says otherwise. `GET /clips` returns an HLS
  playlist, for example.
* IDs are lowercase UUIDs.
* Timestamps are RFC 3339 strings in UTC, such as `"2026-01-15T10:30:00Z"`. The one exception is
  `expires_at` in the `POST /tokens` response, which is a Unix timestamp in seconds.
* Model names are always fully qualified as `owner/name`, such as `reactor/helios`. To name a
  non-production environment of a model, add it after a colon: `your-org/your-model:staging`.
* List endpoints are paginated with `limit` and either `offset` or an opaque `cursor`. Each endpoint
  page names which one it uses, and its default and maximum page size.

## Errors

An error response has a JSON body with an `error` field.

```json theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
{
  "error": "not_found",
  "message": "environment 'staging' does not exist",
  "resource": "environment"
}
```

Newer endpoints put a stable code in `error` and a sentence in `message`. Older endpoints put only a
sentence in `error`. When `message` is present, branch on `error` and show `message` to people.
Never parse `message`: its wording can change.

| `error` | Status | What to do |
| - | - | - |
| `invalid_request` | `400` | Fix the request. `message` names the field. |
| `invalid_cursor` | `400` | Start again from the first page. |
| `forbidden` | `403` | Get access, or name a resource you can see. |
| `not_found` | `404` | Fix the name or ID. `resource` names the type. |
| `method_not_allowed` | `405` | Use a method from the `Allow` header. |
| `already_exists` | `409` | Choose another name, or read the existing resource. |
| `failed_precondition` | `409` | Do not retry unchanged. `reason` names the state to change. |
| `aborted` | `409` | Nothing was written. Read again, then send again. |
| `etag_mismatch` | `412` | Nothing was written. Read the resource again before you decide. |
| `quota_exceeded` | `429` | Retry after the `Retry-After` header. |
| `internal` | `500` | Report it to [support](https://docs.reactor.inc/resources/support.md). |
| `unavailable` | `503` | Retry with backoff. |

### `403` or `404`

A resource outside your permission boundary returns `403 Forbidden`, whether it exists or not. For
example, another account's session or private model returns `403`. A `404 Not Found` means the
resource is absent and you would be allowed to see it. So a `403` on an ID that looks valid usually
means a credential or account problem, not a typo.

`POST /sessions` is the one exception: a model you may not use returns `404`, the same as a model
that does not exist.

### Capacity and quotas

`POST /sessions` returns `429` when an account quota is reached or when no capacity is ready for the
model yet. Both are temporary, so retry after `Retry-After`. A `503` means a service the request
depends on is unavailable. It is not a capacity signal. See [Rate limits](https://docs.reactor.inc/resources/rate-limits.md)
for the quotas that apply to your account.

## Endpoint groups

> [card] [Tokens](https://docs.reactor.inc/platform-api/tokens/create-a-session-token.md)
>
> Mint session tokens from an API key, limited to the models and sessions you choose.

> [card] [Sessions and transport](https://docs.reactor.inc/platform-api/sessions/create-a-session.md)
>
> Start, inspect, and end sessions. Negotiate WebRTC, upload files, and fetch recordings.

> [card] [Users and accounts](https://docs.reactor.inc/platform-api/users/get-the-current-user.md)
>
> Read your user, accounts, invitations, quotas, credit balance, and session history.

> [card] [Models and deployments](https://docs.reactor.inc/platform-api/models/list-models.md)
>
> Register models and releases, upload weights and images, and manage projects and environments.

## See also

> [card] [Using the SDK](https://docs.reactor.inc/sdk-reference/using-the-sdk.md)
>
> The client SDKs wrap the session and transport endpoints and the WebRTC connection.

> [card] [Sessions](https://docs.reactor.inc/concepts/sessions.md)
>
> What a session is, and how its lifecycle, tracks, commands, and messages fit together.

> [card] [CLI & Platform](https://docs.reactor.inc/deploy/platform/overview.md)
>
> The `reactor` CLI wraps the model, release, and deployment endpoints.

> [card] [Client authentication](https://docs.reactor.inc/authentication.md)
>
> Mint tokens from a server and pass them to the JavaScript, Python, and mobile SDKs.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.