There’s a lot of ambiguity around API versioning, making it difficult for people to choose one way to version APIs. But most often, API Providers manage different versions of their API (main, public, beta, deprecated etc) on their docs. They then communicate about the changes with their customers thanks to API version release notes.
API versioning is handled on Blobr in a seamless way. Since you build API products that your users subscribe to, we know who consumes what. When you add a new version of your API source, you may decide to replicate the changes to the API products. In this case, you can send a changelog communication to your users on your behalf. This ensures that they don’t miss anything, especially since the information is tailored to their use case. Instead of reading a lengthy API version release note, they will receive a changelog communication that is only relevant to the endpoints they benefit from.
If you have breaking changes with your API, you can duplicate your existing API product to create a new one and change the version of the API source. As a consequence, you will be able to turn the newly created API product as public and the old product as private. It means that your users can still access the old API products and new users will only see your API products with the new version. You can then communicate to your old users when you want them to move to the new version of the API.
This way of managing API versions helps to reduce the need to create and communicate new API versions to all users.