> ## 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.

# End a session

> Ends the session in any state, including `ACTIVE`, and releases its instance. An ended
session cannot be restarted.

Only the user who started the session may end it. An API key acts as the user who owns
it, so a server holding the key can end sessions started with any session token minted
from that user's keys. A session token can end only the sessions bound to it.

The optional `reason` (at most 256 bytes) is kept and returned as `ended.message`, with
`ended.reason` `USER_REQUEST`, to anyone who can read the session, including the holder of
a session token. Send only text that reader may see.




## OpenAPI

````yaml /openapi.yaml delete /sessions/{session_id}
openapi: 3.1.0
info:
  title: Reactor Platform API
  version: '1'
  description: >
    The Reactor Platform API mints session tokens, starts and operates sessions,
    negotiates media

    transport, and manages your account, models, and deployments. Every path is
    relative to

    `https://api.reactor.inc`. See the
    [Introduction](/platform-api/introduction) and

    [Authentication](/platform-api/authentication) pages for credentials,
    versioning, and errors.
  contact:
    name: Reactor support
    url: https://docs.reactor.inc/resources/support
servers:
  - url: https://api.reactor.inc
    description: Production
security:
  - apiKey: []
tags:
  - name: Status
    description: >-
      Public, unauthenticated endpoints for service health, pricing, and the
      values the API accepts.
  - name: Tokens
    description: >
      Exchange a long-lived API key for a short-lived, session-scoped token that
      a client can use

      to create and operate sessions without holding the key.
  - name: Users
    description: >
      Read your own user record, your account's roster, and account memberships,
      and manage

      member roles as an account admin.
  - name: API Keys
    description: >-
      Revoke API keys. Use the [Dashboard](https://reactor.inc/dashboard) to
      list or create keys. The CLI can also create a key with `reactor auth
      login`.
  - name: Sessions
    description: >
      Create, inspect, and end sessions. A session holds one running model for
      one client

      application; media and messages flow over a transport you attach to it
      afterwards.
  - name: Transport
    description: >
      Attach a client to a session. WebRTC signaling carries ICE servers, SDP,
      and ICE candidates;

      a LiveKit room connection lets the session join a room you host.
  - name: Files
    description: >
      Upload files a model reads, either for one running session or ahead of
      time for sessions you

      have not started yet.
  - name: Recordings
    description: >
      Fetch the recorded video of a session as an HLS playlist, during the
      session or after it ends.
  - name: Accounts
    description: >
      Read and manage the account your credential acts in: its name and slug,
      its credit

      balance, its effective quotas, and its accelerator capacity.
  - name: Invitations
    description: >
      Invite people to your account by email, and manage pending invitations.
      The recipient

      accepts from the emailed link while signed in to the dashboard.
  - name: Usage
    description: >
      List the sessions your account has run, filter them by status, date,
      model, or API key,

      and read exact session totals for a date window.
  - name: Models
    description: >
      Register, read, update, and delete the models your account serves, and
      list the models you can

      use. The `reactor model` CLI commands are built on these endpoints.
  - name: Releases
    description: >
      Register a model's versioned releases, push their container image, and
      deploy a release with a

      per-region instance plan.
  - name: Model Weights
    description: >
      Upload and inspect the weights bundle of a release: single-request
      uploads, multipart uploads

      for large files, and the server-side finalize that marks a bundle
      complete.
  - name: Model Schemas
    description: >
      Attach an OpenAPI schema to a release that describes the model's commands,
      messages, and

      tracks. Schemas of public models are readable without credentials.
  - name: Model Access
    description: |
      Share a private model with other accounts, one environment at a time.
  - name: Projects
    description: >
      A project is the deploy identity of a model you serve on Reactor. Each
      model is one

      project, with its own UUID. Creating a project also creates its
      `production` environment.
  - name: Environments
    description: >
      An environment is a named deploy target of a project, such as `production`
      or `staging`.

      Each write to an environment creates its next revision, and the newest
      revision is what the

      environment runs. Environment access grants let another account start
      sessions on one

      environment.
  - name: Revisions
    description: >
      A revision is an immutable, numbered snapshot of one environment: its
      model image, weights,

      resources, instances, and variables. An environment's revisions, newest
      first, are its change

      log.
  - name: Images
    description: >
      Model images are the container images pushed to your model's repository,
      named by digest.

      Experimental: this API can change without notice.
  - name: Weight Sets
    description: >
      A weight set is a version-2 weights bundle, named by its set digest. Push
      the files, then put

      the manifest. Available when weight sets are enabled for your account.
      Experimental: this API

      can change without notice.
  - name: Tags
    description: >
      A tag is a movable name on one model image or one weight set of a project.
      A release of the

      model is a read-only tag. Experimental: this API can change without
      notice.
paths:
  /sessions/{session_id}:
    parameters:
      - $ref: '#/components/parameters/SessionId'
    delete:
      tags:
        - Sessions
      summary: End a session
      description: >
        Ends the session in any state, including `ACTIVE`, and releases its
        instance. An ended

        session cannot be restarted.


        Only the user who started the session may end it. An API key acts as the
        user who owns

        it, so a server holding the key can end sessions started with any
        session token minted

        from that user's keys. A session token can end only the sessions bound
        to it.


        The optional `reason` (at most 256 bytes) is kept and returned as
        `ended.message`, with

        `ended.reason` `USER_REQUEST`, to anyone who can read the session,
        including the holder of

        a session token. Send only text that reader may see.
      operationId: deleteSession
      parameters:
        - $ref: '#/components/parameters/ApiVersion'
      requestBody:
        required: false
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/SessionDeleteRequest'
            example:
              reason: User closed the tab
      responses:
        '200':
          description: The session was ended. The body is empty.
        '400':
          description: '`session_id` is not a UUID, or `reason` is longer than 256 bytes.'
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
        '401':
          $ref: '#/components/responses/Unauthorized'
        '403':
          description: >
            The caller did not start this session, or the session does not
            exist. The two answer

            the same.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
      security:
        - apiKey: []
        - sessionToken: []
components:
  parameters:
    SessionId:
      name: session_id
      in: path
      required: true
      description: The session's ID, as returned by `POST /sessions`.
      schema:
        type: string
        format: uuid
    ApiVersion:
      name: Reactor-API-Version
      in: header
      required: false
      description: >-
        The API protocol version the client speaks. Currently `1`. Older
        versions than the server's minimum get `426`.
      schema:
        type: string
        example: '1'
  schemas:
    SessionDeleteRequest:
      type: object
      properties:
        reason:
          type: string
          maxLength: 256
          description: >-
            Why the session is ending, at most 256 bytes. Returned as
            `ended.message`.
    Error:
      type: object
      required:
        - error
      properties:
        error:
          type: string
          description: >-
            A stable error code (for example `not_found`) on newer routes, or a
            sentence on older ones. When `message` is present, branch on
            `error`.
        message:
          type: string
          description: >-
            A human-readable explanation. Do not parse it; its wording may
            change.
        resource:
          type: string
          description: The type of the resource a `not_found` refers to.
        reason:
          type: string
          description: >-
            A more specific cause for `failed_precondition`, `aborted`, and some
            `invalid_request` errors.
  responses:
    Unauthorized:
      description: The credential is missing, invalid, or expired.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
  securitySchemes:
    apiKey:
      type: http
      scheme: bearer
      description: >-
        A Reactor API key (`rk_...`), sent as `Authorization: Bearer rk_...`.
        Keep it on a server.
    sessionToken:
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: >-
        A session-scoped JWT minted by `POST /tokens`. Accepted on `/sessions`
        and `/clips` only.

````

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