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

# Versioning and compatibility

> What can change within v1, what never does, and how to write a client that keeps working.

Every endpoint lives under `/v1`. Within `v1`, changes are additive: an integration that follows the rules below keeps working as the API grows.

## Changes within v1

These can happen at any time, without notice:

* New endpoints and new stream channels.
* New optional request parameters and filter fields.
* New fields in responses and stream updates.
* New error codes.
* New chains.
* New values in open sets, such as a trade's `flags`, a token's `dexes` and `launchpad`, a platform's `platform`, and an identity's `source`.

## Changes that need a new version

These never happen within `v1`. They would ship under a new path, such as `/v2`:

* Removing or renaming a field.
* Changing a field's type or unit.
* Changing what an error code means.
* Removing a chain.

## Write a client that keeps working

* **Ignore unknown fields.** Do not reject a response because it carries a field you did not expect.
* **Keep unknown values.** When a value in an open set is new to you, store or skip it, but do not fail.
* **Fall back on the status.** When an error `code` is new to you, handle the response by its HTTP status.
* **Generate clients leniently.** The OpenAPI document publishes trade `flags` as plain strings, but it still publishes `chain`, an identity's `source` and a platform's `platform` as closed enums. Configure your generator to accept unknown enum values, or treat these fields as strings, so a new value does not break deserialization.

Changes are recorded in the [changelog](/resources/changelog).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.