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

# Versioning

> v2 is current and stable; v1 is legacy and deprecated. How changes ship.

The CreatorAudit API is versioned in the URL path. The current, stable version is
`v2` — build new integrations on it.

## Current and legacy versions

| Version | Base URL                          | Status             |
| ------- | --------------------------------- | ------------------ |
| `v2`    | `https://api.creatoraudit.com/v2` | Current, stable    |
| `v1`    | `https://api.creatoraudit.com/v1` | Legacy, deprecated |

`v1` remains available for existing integrations but receives no new features.
Start new work on `v2`, and migrate `v1` integrations when you can.

<Note>
  `v2` reports its stability as `current`. If you are still on `v1`, plan a move to `v2`
  — see [Introduction](/api-reference/introduction) for the envelope and conventions
  you'll be coding against, and the [migration guide](/migration) for the practical,
  path-by-path steps to move off `v1`.
</Note>

## Discover the version at runtime

`GET /v2/meta` is an unauthenticated discovery document that advertises the API's
version and lifecycle. Use it to confirm the version you are talking to and to find
the canonical docs and spec URLs:

```bash theme={null}
curl https://api.creatoraudit.com/v2/meta
```

```json theme={null}
{
  "data": {
    "type": "api_meta",
    "api_version": "v2",
    "status": "current",
    "docs_url": "https://api.creatoraudit.com/v2/docs",
    "openapi_url": "https://api.creatoraudit.com/v2/openapi.json",
    "whoami_url": "https://api.creatoraudit.com/v2/whoami",
    "deprecation": null,
    "sunset": null
  }
}
```

The `deprecation` and `sunset` fields are `null` while a version is fully
supported; they carry dates once a version is on a retirement path.

## How changes ship

* **Additive changes can appear within `v2`.** New endpoints, new optional request
  parameters, and new fields on existing responses can be added to `v2` without a
  version bump. Write clients that **ignore unknown fields** so additive changes
  don't break you.
* **Breaking changes ship as a new major version.** Removing or renaming a field,
  changing a type, or altering required parameters happens in a new version path
  (for example, a future `v3`) — never silently within `v2`.

<Warning>
  Don't hard-code assumptions that a response has *exactly* a fixed set of fields. Read
  the fields you need, tolerate extras, and the additive changes above will never break
  your integration.
</Warning>

## Deprecation stance

When a version is slated for retirement, its `GET /meta` document begins reporting
`deprecation` and `sunset` dates so you can discover the timeline programmatically.
We give advance notice before sunsetting a version. Build your integration to read
`/v2/meta` periodically and surface a deprecation warning to your team if those
fields become non-null.

Questions about a migration timeline? Contact
[support@creatoraudit.com](mailto:support@creatoraudit.com).