From now on, we will start sharing selected parts under development from the API to have potential consumers in the loop and get early feedback.
The respective endpoints are marked with beta or draft. These stability levels come with specific guarantees:
| Level | Change Policy | Minimum Deprecation Period | Comment |
|---|---|---|---|
| draft | breaking changes allowed any time | n/a | Quick iterations, useful to get early validation for API designs. We’ll use this forum for related discussions. |
| beta | breaking changes discouraged, but allowed with 2 weeks notification | 2 weeks | Breaking changes are still possible, but we try to avoid them. When adopting beta APIs, you need to understand the trade-off between getting access to new functionality earlier, but committing to live with the occasional breaking change and need to update. Suitable for products under active development. When you’re actively developing an app/integration, you can likely deal with this level of stability. |
| stable | no breaking changes allowed | 6 months | Stable APIs, we expect your business to rely on them not to change. Deprecations will be carefully communicated. We’ll remind users regularly if there are breaking changes that affect will affect you. |
[!tip]
Sometimes we might chose to make breaking changes without respecting the deprecation period. This can become neccessary for security reasons or when we see (very) limited usage of the feature in question. In these cases, we will reach out to each consumer individually to work out an exception together.
Here is how stability levels are displayed in the documentation.
As always, if you have any questions, do not hesitate to reach out!
This supersedes Update: Alpha State APIs.
Also, unicorns, in different stability levels.
