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

# Versioning

export const EndOfLifeBadge = ({size = "sm"}) => <Tooltip tip="No longer supported; may lose server compatibility">
        <Badge icon="ban" color="red" size={size}>End of life</Badge>
    </Tooltip>;

export const SupportedBadge = ({size = "sm"}) => <Tooltip tip="Actively maintained with bug fixes and security patches">
        <Badge icon="circle-check" color="green" size={size}>Supported</Badge>
    </Tooltip>;

export const LinkNewTab = ({href, children}) => <a href={href} target="_blank" rel="noopener noreferrer">
    {children}
  </a>;

export const CardNewTab = ({children, ...props}) => {
  const ref = React.useRef(null);
  React.useEffect(() => {
    if (!ref.current) return;
    const anchor = ref.current.querySelector('a[href]');
    if (anchor) {
      anchor.setAttribute('target', '_blank');
      anchor.setAttribute('rel', 'noopener noreferrer');
    }
  }, []);
  return <div ref={ref} style={{
    display: 'contents'
  }}>
      <Card {...props}>
        {children}
      </Card>
    </div>;
};

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.

```bash theme={null}
curl --request GET \
  --url 'https://api.mirurobotics.com/beta/devices' \
  --header 'X-API-Key: <api-key>' \
  --header 'Miru-Version: 2026-05-06.rainier'
```

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 Version                                                                            | EOL        | Status             |
| -------------------------------------------------------------------------------------- | ---------- | ------------------ |
| <LinkNewTab href="/references/platform-api/2026-05-06">2026-05-06.rainier</LinkNewTab> | —          | <SupportedBadge /> |
| <LinkNewTab href="/references/platform-api/2026-03-09">2026-03-09.tetons</LinkNewTab>  | —          | <SupportedBadge /> |
| <LinkNewTab href="/references/platform-api/2025-10-21">2025-10-21.zion</LinkNewTab>    | 2026-06-16 | <EndOfLifeBadge /> |

## Changelog and migrations

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

<CardNewTab href="/changelog/platform-api" title="Platform API Changelog" icon="scroll-text" arrow>
  Changelog and migration steps for the Platform API.
</CardNewTab>

## 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](/changelog/platform-api). 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