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

# Platform API overview: augment datasets and train policies on demand

> A small, predictable REST API for running the Kite platform from your own code — dataset augmentation, policy training, and async runs on cloud GPUs.

The Kite Platform API lets you run the platform programmatically. Today that means generating **augmented robotics datasets**, **training policies** on managed GPUs, **training robot policies in simulation** with reinforcement learning, and — in private beta — rebuilding a robot episode as an interactable **digital twin**. Point Kite at a dataset, say what you want, and Kite does the work on its GPUs and delivers a ready-to-train dataset or a trained policy.

## Base URL

All requests go to:

```
https://api.kiteml.com/v1
```

Every request is authenticated with an API key sent as a Bearer token. See [Authentication](/platform-api/authentication).

## What you can run

There's no infrastructure to manage. Every resource runs on Kite's infrastructure and delivers standard artifacts: LeRobot datasets and policies, and MuJoCo scenes.

<Steps>
  <Step title="Augmentations">
    Point Kite at a LeRobot dataset, describe a visual change in plain language, and get back new episodes with the robot's motion preserved. See [Augmentations](/platform-api/augmentation).
  </Step>

  <Step title="Training runs">
    Point Kite at a LeRobot dataset, pick your policies and a GPU tier, and get back trained checkpoints. See [Training runs](/platform-api/training-runs).
  </Step>

  <Step title="Twins (private beta)">
    Point Kite at one episode of a LeRobot dataset and get back an interactable MuJoCo scene of the room, in one verified download. See [Twins](/platform-api/twins).
  </Step>

  <Step title="RL runs">
    Describe a behavior for a robot as a task spec and get back a policy trained in simulation: ONNX, the MuJoCo scene it trained in, clips, and a verdict from measured checks. See [RL runs](/platform-api/rl-runs).
  </Step>
</Steps>

## Asynchronous by design

Runs are asynchronous. Creating one returns immediately with an `id`; you then poll it as it progresses through `processing → succeeded`, or register a [webhook](/platform-api/api-reference) and skip polling. `failed` and `canceled` are the other terminal states.

Every resource shares that status vocabulary, and `GET /v1/operations/:id` reports it uniformly for any id — so one polling loop handles them all.

A completed augmentation gives you a standard LeRobot dataset: Parquet tables for states and actions plus MP4 camera video. A completed training run gives you a standard LeRobot policy checkpoint. Neither is a proprietary format.

## Conventions

<Info>
  Every endpoint has its own page under **API reference**: parameters, request body, response fields, and errors, generated from the OpenAPI document the API publishes at `https://api.kiteml.com/v1/openapi.json`.
</Info>

* **JSON everywhere.** Requests and responses are `application/json` unless noted.
* **Resource ids are prefixed** — an augmentation is `aug_…`, a training run is `trn_…`, a twin is `twin_…`, an RL run is `rlr_…`, an API key is `key_…` — so they're easy to recognize in logs.
* **Timestamps are ISO 8601** in UTC (e.g. `2026-07-21T09:14:00Z`).
* **Idempotency is supported** on run creation via an `Idempotency-Key` header — see [Augmentations](/platform-api/augmentation#idempotency) and [Training runs](/platform-api/training-runs#idempotency).
* **Lists are cursor-paginated** — pass the response's `next_cursor` back as `after`, and stop when `has_more` is false. There is no offset paging.
* **Versions are dated.** Send `Kite-Version: 2026-09-27` to pin the contract your code was written against, the way Anthropic's `anthropic-version` and Stripe's `Stripe-Version` work. Every response carries the version that served it. A breaking change ships under a new date, so code pinned to an older date keeps working; a request without the header gets the first version. An unknown date returns `400` with code `unsupported_version`.


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