How to maintain hundreds of API Versions and survive

Stanislav Zmiev

from Monite (Tbilisi)

About speaker

Platform Engineer, active open-source contributor, extreme type hint enjoyer.

My specialty is Backend Development but I have done a fair share of frontend, mobile, DevOps, and lower level stuff.

About speakers company

Monite was born in Berlin in 2020, with a founding mission to automate finance for SMEs. Soon after, Monite raised a € 1.1 million pre-seed round with Tomahawk VC, Signals VC, Possible Ventures, and Runa Capital. We want to turn B2B platforms, neobanks, and fintechs into super-apps that solve this problem with automated invoicing, payables, and B2B payments.



Web API Versioning is a way to allow your developers to move quickly and break things while your clients enjoy the stable API in long cycles. It is best practice for any API-first company. Without versioning, the company will either be unable to improve their API, or their clients will have their integrations broken every few months.

The problem is that there is no information on how to implement it: If you try searching for methods of API versioning, you will see hundreds of articles on whether to put the version into the URL or a header, a few pieces of ASP.NET documentation, and a single article by Stripe that delves deep into the subject matter. Sadly, even they only describe one approach.

I'll cover all sorts of ways you can pick to implement API versioning: extremely stable and expensive, easy-looking but horrible in practice, and even completely version-less yet viable. I will provide you with the best practices for creating a modern API versioning solution and discuss what Stripe and Monite have chosen for their APIs.

When you leave, you'll have enough information to make your API versioning user-friendly without overburdening your developers.

The talk was declined

other talks of this topic