3 ms·
How does Stripe do date-based API versioning?
Stripe uses a date-based versioning system for its API. This means that each new version of the API is identified by a specific date, like 2023-10-16.
When they introduce backwards-incompatible changes to the API, they release a new version with the current date. This ensures older integrations don't break unexpectedly.
When you first make an API request to Stripe, your account is automatically pinned to the latest available version. This means all subsequent requests from your account will use that version by default.
You can override the version manually through a special request header or via their dashboard.
This is a really elegant and developer friendly approach and allows them to make changes and improve their API more frequently but at the same time, it seems to me like it's very hard to maintain internally.
How are they taking care of all the code branching internally without this becoming a total mess ?
How much overhead is involved in supporting such versioning scheme and do you think it's worth for other companies to adopt this ?
- chasselschwert 3y ago[dead]
- MichaelMug 3y ago> How are they taking care of all the code branching internally without this becoming a total mess ? I am also interested in this.
- ale_jacques 3y agoOno approach could be using branches for development flow and tags for the releases. That way you can keep your branches "separated" from the deployed releases (deploying those commit tags).
- pushcx 3y agoStripe posted an explanation here: https://stripe.com/blog/api-versioning https://stripe.com/blog/api-versioning
- mderazon 3y agoSmart approach, writing their own DSL for version change and applying them backwards for each request. I wish they would open source this