News for hackers. Stuff that matters.

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 ?

( 4 comments | 3 points | on HN )
Re:How does Stripe do date-based API versioning? by ale_jacques on Thursday January 11, 2024 @06:17AM (#38950727)
Ono 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).
Re:How does Stripe do date-based API versioning? by MichaelMug on Thursday January 11, 2024 @05:46AM (#38950462)
> How are they taking care of all the code branching internally without this becoming a total mess ?

I am also interested in this.

Re:How does Stripe do date-based API versioning? by pushcx on Thursday January 11, 2024 @05:38PM (#38960419)
Stripe posted an explanation here: https://stripe.com/blog/api-versioning
Re:How does Stripe do date-based API versioning? by mderazon on Friday January 12, 2024 @03:44AM (#38965632)
Smart approach, writing their own DSL for version change and applying them backwards for each request.

I wish they would open source this