API Deprecation Policy
This policy says how much notice you get before a change to the Routebase public API can break your integration, and where that notice appears.
What this policy covers
The policy covers every operation in the Routebase Public API reference. Endpoints that the web app or the desktop app call but the reference does not list are not covered, and they can change without notice.
What counts as a breaking change
A change is breaking when a client that follows the published contract can stop working because of it. These changes are breaking:
- Removing an operation, a parameter or a response field.
- Renaming any of them, or changing the type of one.
- Adding a required parameter or a required request field.
- Removing a value from an enum in a request.
- Requiring a permission or an API key scope that was not required before.
These changes are not breaking, so your client should tolerate them:
- Adding an operation, an optional parameter or a response field.
- Adding a value to an enum in a response.
- Changing the wording of a description or an error message.
Notice period
We announce a breaking change at least 90 days before it takes effect.
The only exception is a change we have to make sooner to close a security vulnerability. In that case we keep the notice as long as the fix allows.
Where you see the notice
Each announcement appears in two places:
- The Release Notes describe the change and name the date it takes effect.
- The OpenAPI document marks an affected operation or parameter with
deprecated: true.
Compare the OpenAPI document in your CI pipeline if you want to catch a deprecation automatically.
The command-line tool
The Routebase CLI has its own version number. Exit codes and flag names are a contract, so a change to either of them is a new major version.
Related
- Rate Limits lists the request limits of the API.
- Deprecation explains how you deprecate endpoints of your own API in Routebase.
- Release Notes list every announced change.