Release management
Bitvavo releases API changes in a predictable and structured way so you can plan, test, and deploy updates without unexpected impact.
Bitvavo uses semantic versioning for public APIs. This section explains how Bitvavo classifies API changes, versions them, and communicates upcoming releases.
Types of changes
Bitvavo uses three types of API changes: an internal change, an external change, or a breaking change.
Internal changes
Internal changes do not affect API behavior that you can observe or rely on. These changes include internal technical improvements and bug fixes that do not alter requests, responses, or event flows.
You do not need to take any action for internal changes.
External changes
External changes are visible to you but remain backward compatible. If you do not adopt the change, your integration continues to work as before.
These changes include adding new endpoints or messages, adding optional parameters, adding new enum values, or changing the ordering of fields.
External changes can result in a minor or a patch version update.
Breaking changes
Breaking changes require action from you. If you do not update your integration, requests may fail or return incorrect results.
These changes include removing or renaming endpoints, removing parameters, adding mandatory parameters, changing data types, changing request or response structures, altering event flow, or changing authentication mechanisms.
Breaking changes result in a major version update.
Communication and timelines
We use our Releases changelog section to communicate upcoming changes ahead of a release. For external changes to the APIs, we strive towards having the sneak preview updated between two and four weeks before the release.
This gives you time to prepare, test, and migrate when required.