# Versioning and deprecation

What can change under you, and what cannot.

The version is in the path (/v1/…). Within a version, Ryde may make backward-compatible changes at any time, and your integration must tolerate them.

| Backward-compatible | Breaking |
| --- | --- |
| A new field in a response | Removing or renaming a field |
| A new optional request field | Making an optional field required |
| A new endpoint or a new scope | Removing an endpoint or a scope |
| A new value in an existing enum | Changing the meaning of a value |
| A new error code | Changing which status an error returns |

> **Note:** Parse leniently: ignore fields you do not recognize, and treat an unknown enum value as a value you cannot handle rather than as an error. A client that rejects unknown fields breaks on the next additive change.

A breaking change ships as a new version with an announcement, a migration guide, a deprecation date and a sunset date. Nothing in production is removed without that sequence.