> Source: [/docs/api/versioning-policy](https://tempo.xyz/developers/docs/api/versioning-policy.md) > Section: [API reference](https://tempo.xyz/developers/docs/api.md). Tempo API reference: authentication, conventions, endpoints grouped by product, Console management endpoints, JSON-RPC, and the indexer. An API key authenticates API requests; an account signing key authorizes transactions. > [Documentation index](https://tempo.xyz/developers/llms.txt) · [Docs skill](https://tempo.xyz/developers/SKILL.md) > Tempo MCP: Use `search`, `find_pages`, `read_page`, and `code` at `https://mcp.tempo.xyz` for Tempo and related documentation. > If an indexed page is missing or reflects an older site, read this site’s [documentation index](https://tempo.xyz/developers/llms.txt) and Markdown pages directly. # Tempo API versioning policy The Tempo API evolves without breaking existing integrations whenever practical. This page explains how the API is versioned, what we consider a breaking change, and how changes are communicated. :::warning The Tempo API is under active development. Endpoints are not yet stable and may change without notice. The policy below will apply after stabilization. ::: ## Versioning scope This policy covers the versioned REST API under `/v1`. It does **not** apply to the following endpoint, which follows an external specification and is versioned independently of the Tempo API: | Endpoint | Description | | --- | --- | | `/rpc` | The Ethereum JSON-RPC interface, which tracks the upstream JSON-RPC and node specifications. | ## Compatible API changes These changes are released continuously and **do not** require you to change your integration or select a new version: * Adding a new endpoint, resource, or response. * Adding new optional request query parameters, headers, or body fields. * Adding new fields, objects, or headers to an existing response. * Adding new values to an open-ended enum or `status` field. * Adding new error `code`s within an existing documented category. * Changing human-readable text, such as descriptions or error `message`s, without changing the machine-readable `code` or its meaning. * Fixing behavior to match the documented API. * Changing the format or length of opaque API resource identifiers and cursors. Onchain addresses and transaction hashes retain their specified formats. * Adding or adjusting `RateLimit-*` headers. ## Breaking API changes A breaking change is any change that could require a correctly implemented client to change code to keep working as documented. Breaking changes are introduced behind an explicit version with a migration path. Examples: * Removing or renaming an endpoint, request parameter, or response field. * Changing the type, format, nullability, or meaning of an existing field. * Making a previously optional request parameter required. * Changing authentication, pagination, or the documented status code or error shape for an existing condition. * Rejecting requests that were previously valid under the documented API. :::warning We may make immediate changes without the usual notice when required to address security, abuse, data-integrity, legal, or chain-safety issues. We document these as soon as practical. ::: ## API deprecation and sunset We will not deprecate a stable endpoint or version until a replacement is available and documented with a migration path. Deprecated endpoints are marked `deprecated: true` in the [Tempo OpenAPI specification](https://api.tempo.xyz/openapi.json) and return standard signaling headers: For example (illustrative dates): ```http Deprecation: @1798761600 Sunset: Fri, 15 Jan 2027 00:00:00 GMT Link: ; rel="deprecation" ``` ## API change notices * All breaking changes and meaningful additions are recorded in the changelog with affected endpoints, migration notes, and any sunset date. * Deprecated operations and fields are flagged in the [Tempo OpenAPI specification](https://api.tempo.xyz/openapi.json).