api-versioning-strategy — Claude Code skill: API versions and sunset
Picks a versioning scheme for your API and walks an old version through deprecation without breaking clients.
npx skills add secondsky/claude-skills --skill api-versioning-strategy -a claude-codeWhat api-versioning-strategy does
The skill compares three ways to version an API: a path segment (/api/v1/users), an API-Version header, and a ?version=1 query parameter. Each gets a pros-and-cons table, and URL paths come out on top — readable and cache-friendly.
Then come the code blocks. Mounting v1 and v2 routers with app.use, an adapter that reshapes a v1 response into the v2 envelope, and middleware that sets Deprecation, Sunset and Link headers pointing at the successor version. A separate table sorts changes into safe ones (optional fields, new endpoints, optional parameters) and breaking ones that force a new version.
The sunset schedule runs in phases: three months deprecated, three months after the sunset announcement, one month read-only, then 410 Gone. The skill advises keeping at least N-1 versions alive and giving a migration window of 6+ months. That matters once outside teams depend on your endpoints, because an old version with no shutdown plan tends to stick around. Samples are JavaScript, so other stacks mean porting the patterns yourself.
What it helps with
- decide between URL, header and query versioning
- split v1 and v2 handlers into separate routers
- reshape old responses into the new format without client changes
- mark a retired version with Deprecation and Sunset headers
- tell a safe contract change from a breaking one
Example prompts for the agent
- Recommend a versioning scheme for our REST API and justify it
- Add middleware that sets Deprecation and Sunset headers on /api/v1
- Draft a sunset timeline for the old version with the phases
How to install api-versioning-strategy
1Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill api-versioning-strategy -a claude-code2Manually: put the files in place
~/.claude/skills/api-versioning-strategy/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/api-versioning-strategy/
1Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill api-versioning-strategy -a codex2Manually: put the files in place
.agents/skills/api-versioning-strategy/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill api-versioning-strategy -a cursor2Manually: put the files in place
.cursor/skills/api-versioning-strategy/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install secondsky/claude-skills api-versioning-strategy2Manually: put the files in place
.github/skills/api-versioning-strategy/SKILL.md1Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill api-versioning-strategy -a gemini-cli2Platform CLI
gemini skills install https://github.com/secondsky/claude-skills --path plugins/api-versioning-strategy/skills/api-versioning-strategyManually: put the files in place
.devin/skills/api-versioning-strategy/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill api-versioning-strategy -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about api-versioning-strategy
How do I install api-versioning-strategy in Claude?
Run npx skills add secondsky/claude-skills --skill api-versioning-strategy -a claude-code. The skill file then lands at ~/.claude/skills/api-versioning-strategy/SKILL.md.
What does api-versioning-strategy do?
It lays out API versioning methods, code patterns for running several versions at once, and a phased process for retiring an old one.
Which changes count as breaking?
Removing fields or endpoints, changing field types, and restructuring responses. Adding optional fields, endpoints or parameters does not need a new version.
Source text
SKILL.md · MIT
---
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.
license: MIT
---
# 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
© secondsky · MIT · secondsky/claude-skills