home / skills / secondsky / claude-skills / api-versioning-strategy
/plugins/api-versioning-strategy/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-strategyReview the files below or copy the command above to add this skill to your agents.
---
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
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.
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.
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.