API Versioning Strategies That Actually Work in Production

API Versioning Strategies That Actually Work in Production You shipped v1 of your API. Now you need breaking changes. Do you break existing clients or maintain two versions forever? Strategy 1: URL Path Versioning /api/v1/users vs /api/v2/users Pros: Explicit, easy to route, clients see version in URL. Used by: Stripe, GitHub, Twilio. Cons: URL bloat, hard to share code between versions. Strategy 2: Header Versioning Accept: application/vnd.myapi.v2+json or X-API-Version: 2 Pros: Clean URLs, version negotiation possible. Used by: GitHub (Accept header). Cons: Hidden complexity, harder to test in browser, easy to forget. Strategy 3: Query Parameter /api/users?version=2 Pros: Easy to implement. Cons: Breaks caching, pollutes query string. Not recommended. Strategy 4: Date-Based (Stripe Style) Stripe-Version: 2024-12-18 Each API key is pinned to the version at creation time. Clients upgrade by changing the version header. Rolling changes, not big-bang migrations. Implementation: Express R