Versioning
When backwards-incompatible changes are made to the API, we release a new, number version. The current version is version 1. For information on all API updates, view our API changelog.
Older versions of the API continue to work as before when we release new versions. We don't automatically change your API version, so your integrations continue to work until you're ready to upgrade.
You can override the API version in your code in all versions.
To override the API version, pass the version to the Bunce base url method, or set it per-request. When overriding it per-request, methods on the returned object reuse the same Bunce version.
Breaking Changes
A breaking change is a change that may require you to make changes to your code to keep your integrations working. They're sometimes called backwards compatible changes.
Some examples of breaking changes:
- Removing or renaming a parameter or field
- Removing or renaming an endpoint or operation
- Changing how an endpoint works
- Adding validation for a field
- Changing error handling
Non-breaking Changes
We may make non-breaking changes to the API. These are changes that don't disrupt existing workflows, so you can adopt them at your own pace. They're sometimes called backwards compatible changes.
Some examples of non-breaking changes:
- Changing field ordering in responses
- Adding new endpoints or operations
- Adding new fields to responses
- Adding new optional request parameters
We'll update our developer changelog with information about non-breaking changes.
Specify a version
https://api.bunce.so/v1 for live environment and https://sandbox.api.bunce.so/v1 for sandbox environment.
As a user, when you are calling the API, use your test key for test mode and live key for live mode.