Skip to main content
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:
Every request is authenticated with an API key sent as a Bearer token. See 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.
1

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

Training runs

Point Kite at a LeRobot dataset, pick your policies and a GPU tier, and get back trained checkpoints. See Training runs.
3

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

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.

​
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 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

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.
  • 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 and Training runs.
  • 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.