Skip to main content
The Platform API uses date-based versioning with a train name. Each version follows the format: 
YYYY-MM-DD.<train>
  • The date is the version’s publish date
  • The train is a codename representing a major release epoch (e.g. tetons)
All changes within a train are backward-compatible. A new train introduces a new epoch that may include breaking changes.

​
Version header

The Platform API uses the Miru-Version header to select the API version you want to use. 
curl --request GET \
  --url 'https://api.mirurobotics.com/beta/devices' \
  --header 'X-API-Key: <api-key>' \
  --header 'Miru-Version: 2026-03-09.tetons'
The Miru-Version header is required. Requests without the header will be rejected.

​
Supported versions

Below is a list of the currently supported versions:
API VersionStatus

​
Changelog and migrations

For a history of changes and migration steps for the Platform API, visit the changelog below.

​
OpenAPI specifications

The Platform API is defined using the OpenAPI 3.0 specification. Each version of the spec is available for download as a YAML file from the Platform API changelog. Use the specs to generate client code, validate requests, or import into tools like Postman and Swagger UI.

​
Support policy

Miru provides three levels of support for the Platform API
  • Supported
  • Deprecated
  • End of life
When a new API version epoch is released (e.g. zion to tetons), previous API epochs may enter a deprecation period. During this period:
  • The deprecated version continues to function normally
  • No new features will be added to the deprecated epoch
Once the deprecation period ends, the API epoch is considered end-of-life and is no longer supported. Requests to an end-of-life epoch will return a 400 Bad Request error.

​
Deprecation notice

Since the Miru Platform API is still in beta, a fixed support schedule for beta releases is not established. Nonetheless, we are committed to ensuring that all users are migrated to a supported version before sunsetting an API version. Reasonable notice will be provided before deprecating and sunsetting any API versions.

​
Stability guarantees

Within a train (e.g. zion), all changes are additive and backward-compatible. You can rely on the API contract remaining stable for the lifetime of a train. When a new train is introduced, it may include breaking changes. Migration guides will be published to help you transition.

​
Breaking changes

The following changes are considered breaking:
  • Removing an endpoint
  • Removing or renaming a response field
  • Changing the type of a response field
  • Adding a new required request parameter
  • Removing or renaming an enum value
  • Changing authentication requirements
  • Changing the structure of error responses

​
Non-breaking changes

The following changes are considered non-breaking:
  • Adding a new endpoint
  • Adding a new optional request parameter
  • Adding a new field to a response
  • Adding a new enum value
  • Adding a new optional header
  • Improving error messages without changing their structure
Last modified on March 15, 2026