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

# Versioning

> Date-based API versions: your key is pinned to a version at creation, breaking changes ship as new dates, and old integrations keep working unchanged.

The Developer API uses **date versions** — `2026-08-22` is the current (and founding) version. When the API needs a breaking change (a renamed field, a reshaped response), that change ships as a **new date**; every older version keeps behaving exactly as it did. Additive changes — new endpoints, new optional fields — arrive in all versions and never mint a date.

<Note>
  You never have to chase the API. An integration built today keeps receiving today's shapes until **you** decide to move — that is the whole point of the model.
</Note>

## Your key is pinned

Every API key is pinned to the version that was current when the key was created. A request without a version header is served in the key's pinned version, forever. The console's [API keys](/en/developers/api-keys) page shows each key's pinned version in the **API version** column.

## Overriding per request

Send the `Orriven-Version` header to serve a single request in a different version — the way to test a newer version before committing to it:

```bash theme={null}
curl -H "Authorization: Bearer $KEY" \
     -H "Orriven-Version: 2026-08-22" \
     "$BASE/v1/events"
```

An unknown date answers `400` and names the versions that exist. You cannot invent a version — only published dates are valid.

## Every response tells you its version

Whatever decided the version — your header or your key's pin — the response echoes it back:

```
Orriven-Version: 2026-08-22
```

Log this header in your integration: when you read old logs during an upgrade, you will know exactly which shape each response was in.

## Upgrading

<Steps>
  <Step title="Read the changelog">
    Each new version's entry (below) says exactly what changed, seen from the caller.
  </Step>

  <Step title="Test with the header">
    Point your staging integration at the new date with `Orriven-Version` — your key's pin is untouched, production traffic keeps its old shape.
  </Step>

  <Step title="Move the pin">
    Generate a new key (it pins to the latest version automatically), switch your integration to it, then revoke the old key — the same zero-downtime rotation as any credential change.
  </Step>
</Steps>

## Changelog

| Version      | Changes                                               |
| ------------ | ----------------------------------------------------- |
| `2026-08-22` | Founding version — the API as documented in this tab. |

## Related

<CardGroup cols={2}>
  <Card title="API keys" icon="key" href="/en/developers/api-keys">
    Where a key's pinned version lives.
  </Card>

  <Card title="Endpoint reference" icon="book" href="/en/developers/api-reference">
    The current version's shapes, endpoint by endpoint.
  </Card>
</CardGroup>