home / skills / secondsky / claude-skills / api-versioning-strategy

This skill helps you implement API versioning strategies with clear deprecation timelines and safe migration paths across v1 and v2.

npx playbooks add skill secondsky/claude-skills --skill api-versioning-strategy

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.1 KB
---
name: api-versioning-strategy
description: Implements API versioning using URL paths, headers, or query parameters with backward compatibility and deprecation strategies. Use when managing multiple API versions, planning breaking changes, or designing migration paths.
---

# API Versioning Strategy

Choose and implement API versioning approaches with proper deprecation timelines.

## Versioning Methods

| Method | Example | Pros | Cons |
|--------|---------|------|------|
| URL Path | `/api/v1/users` | Clear, cache-friendly | URL clutter |
| Header | `API-Version: 1` | Clean URLs | Hidden, harder to test |
| Query | `?version=1` | Easy to use | Not RESTful |

## URL Path Versioning (Recommended)

```javascript
const v1Router = require('./routes/v1');
const v2Router = require('./routes/v2');

app.use('/api/v1', v1Router);
app.use('/api/v2', v2Router);
```

## Version Adapter Pattern

```javascript
// Transform between versions
const v1ToV2 = (v1Response) => ({
  data: {
    type: 'user',
    id: v1Response.user_id,
    attributes: {
      name: v1Response.user_name,
      email: v1Response.email
    }
  }
});
```

## Deprecation Headers

```javascript
app.use('/api/v1', (req, res, next) => {
  res.setHeader('Deprecation', 'true');
  res.setHeader('Sunset', 'Sat, 01 Jun 2025 00:00:00 GMT');
  res.setHeader('Link', '</api/v2>; rel="successor-version"');
  next();
});
```

## Safe vs Breaking Changes

**Safe Changes** (no version bump):
- Adding optional fields
- Adding new endpoints
- Adding optional parameters

**Breaking Changes** (requires new version):
- Removing fields
- Changing field types
- Restructuring responses
- Removing endpoints

## Deprecation Timeline

| Phase | Duration | Actions |
|-------|----------|---------|
| Deprecated | 3 months | Add headers, docs |
| Sunset Announced | 3 months | Email users |
| Read-Only | 1 month | Disable writes |
| Shutdown | - | Return 410 Gone |

## Best Practices

- Support N-1 versions minimum
- Provide 6+ months migration window
- Include migration guides with code examples
- Monitor version usage to inform deprecation

Overview

This skill implements API versioning strategies using URL paths, headers, or query parameters and includes backward compatibility and deprecation workflows. It provides concrete patterns like path-based versioning, adapter transforms between versions, and deprecation headers to communicate timelines. The goal is to make multi-version API maintenance predictable and safe when planning breaking changes or migrations.

How this skill works

The skill wires versioned routes (for example /api/v1 and /api/v2) and supports header- or query-based detection when needed. It supplies adapter functions to transform requests or responses between versions so older clients remain supported. It also injects deprecation headers and enforces phased sunset steps (Deprecated, Sunset Announced, Read-Only, Shutdown) with configurable timelines.

When to use it

  • Managing multiple active API versions and needing clear compatibility rules
  • Planning breaking changes while keeping older clients functional
  • Providing migration paths and code examples for client developers
  • Enforcing deprecation timelines and communicating sunsets
  • Supporting internal and partner integrations that lag behind releases

Best practices

  • Prefer URL path versioning for clarity and cache friendliness
  • Keep at least N-1 versions supported and aim for 6+ months migration windows
  • Use adapter/transform patterns to minimize duplicate logic across versions
  • Emit Deprecation, Sunset, and successor Link headers to notify clients
  • Monitor version usage and base deprecation decisions on real traffic

Example use cases

  • Expose /api/v1 and /api/v2 routers with middleware that sets Deprecation and Sunset headers for v1
  • Implement v1-to-v2 adapters that reshape payloads to new field names and types
  • Accept API-Version header for internal services while keeping public path-based URLs
  • Run a phased shutdown: mark deprecated, notify users, switch to read-only, then return 410
  • Provide migration guides and code snippets showing request/response adaptations

FAQ

Which versioning method is recommended?

URL path versioning is recommended for clarity and caching; use headers for cleaner URLs in controlled environments.

When does a change require a new version?

Any breaking change—removing fields, changing types, or restructuring responses—requires a new version.