
Api Changelog Versioning
- 427 installs
- 305 repo stars
- Updated March 4, 2026
- aj-geddes/useful-ai-prompts
api-changelog-versioning is a prompt skill from aj-geddes/useful-ai-prompts that designs semver rules, deprecation notices, and changelog entries when developers add or change public API endpoints and response contracts.
About
api-changelog-versioning is a focused prompt skill in the aj-geddes/useful-ai-prompts collection for backend developers shipping REST or GraphQL API changes. The skill guides semver decision-making, drafts deprecation notices for retiring fields or routes, and writes changelog entries that document endpoint additions, breaking changes, and response contract updates. Developers reach for api-changelog-versioning when a PR touches public API surfaces and release notes must communicate version bumps, migration paths, and sunset timelines to API consumers before merge or tag.
- Defines semver and breaking-change policy
- Drafts structured API changelog entries
- Plans deprecation and sunset timelines
- Aligns version bumps with endpoint changes
Api Changelog Versioning by the numbers
- 427 all-time installs (skills.sh)
- Ranked #1,031 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/aj-geddes/useful-ai-prompts --skill api-changelog-versioningAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 427 |
|---|---|
| repo stars | ★ 305 |
| Last updated | March 4, 2026 |
| Repository | aj-geddes/useful-ai-prompts ↗ |
How do you version public API breaking changes?
Design semver rules, deprecation notices, and changelog entries when adding or changing public API endpoints and response contracts.
Who is it for?
Backend developers shipping public API changes who need semver-aligned changelog and deprecation copy before release.
Skip if: Internal-only refactors with no public contract changes where changelog and deprecation communication is unnecessary.
When should I use this skill?
A developer adds, modifies, or removes public API endpoints or response schemas and needs release documentation.
What you get
Semver rules, deprecation notices, and changelog entries documenting API endpoint and response contract changes.
- CHANGELOG entry
- deprecation notice
- semver version bump recommendation
Files
API Changelog & Versioning
Table of Contents
Overview
Create comprehensive API changelogs that document changes, deprecations, breaking changes, and provide migration guides for API consumers.
When to Use
- API version changelogs
- Breaking changes documentation
- Migration guides between versions
- Deprecation notices
- API upgrade guides
- Backward compatibility notes
- Version comparison
Quick Start
- Version comparison
````markdown
API Changelog
Version 3.0.0 - 2025-01-15
🚨 Breaking Changes
Authentication Method Changed
Previous (v2):
GET /api/users
Authorization: Token abc123Reference Guides
Detailed implementations in the references/ directory:
| Guide | Contents |
|---|---|
| 🚨 Breaking Changes | 🚨 Breaking Changes |
| ✨ New Features | ✨ New Features |
| 🔧 Improvements | 🔧 Improvements |
| 🔒 Security | 🔒 Security, 🗑️ Deprecated, 📊 Version Support Policy |
| Step 1: Update Base URL | Step 1: Update Base URL, Step 2: Migrate Authentication, Step 3: Update Response Parsing, Step 4: Update Error Handling (+2 more) |
Best Practices
✅ DO
- Clearly mark breaking changes
- Provide migration guides with code examples
- Include before/after comparisons
- Document deprecation timelines
- Show impact on existing implementations
- Provide SDKs for major versions
- Use semantic versioning
- Give advance notice (3-6 months)
- Maintain backward compatibility when possible
- Document version support policy
❌ DON'T
- Make breaking changes without notice
- Remove endpoints without deprecation period
- Skip migration examples
- Forget to version your API
- Change behavior without documentation
- Rush deprecations
🚨 Breaking Changes
🚨 Breaking Changes
Authentication Method Changed
Previous (v2):
GET /api/users
Authorization: Token abc123````
Current (v3):
GET /api/v3/users
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...Impact: All API consumers must switch from API tokens to JWT Bearer tokens
Migration Steps:
1. Obtain JWT token from /api/v3/auth/login endpoint 2. Replace Authorization: Token with Authorization: Bearer 3. Update token refresh logic (JWT tokens expire after 1 hour)
Migration Deadline: June 1, 2025 (v2 auth will be deprecated)
Migration Guide: JWT Authentication Guide
---
Response Format Changed
Previous (v2):
{
"id": "123",
"name": "John Doe",
"email": "john@example.com"
}Current (v3):
{
"data": {
"id": "123",
"type": "user",
"attributes": {
"name": "John Doe",
"email": "john@example.com"
}
}
}Impact: All API responses now follow JSON:API specification
Migration:
// Before (v2)
const user = await response.json();
console.log(user.name);
// After (v3)
const { data } = await response.json();
console.log(data.attributes.name);
// Or use our SDK which handles this automatically
import { ApiClient } from "@company/api-sdk";
const user = await client.users.get("123");
console.log(user.name); // SDK unwraps the response---
Removed Endpoints
| Removed Endpoint | Replacement | Notes |
|---|---|---|
GET /api/users/list | GET /api/v3/users | Use pagination parameters |
POST /api/users/create | POST /api/v3/users | RESTful convention |
GET /api/search | GET /api/v3/search | Now supports advanced filters |
---
🔧 Improvements
🔧 Improvements
Performance Enhancements
- 50% faster response times for list endpoints
- Database query optimization reducing average query time from 150ms to 50ms
- Caching layer added for frequently accessed resources
- CDN integration for static assets
Benchmark Comparison:
| Endpoint | v2 (avg) | v3 (avg) | Improvement |
|---|---|---|---|
| GET /users | 320ms | 140ms | 56% faster |
| GET /users/{id} | 180ms | 60ms | 67% faster |
| POST /users | 250ms | 120ms | 52% faster |
---
Better Error Messages
Before (v2):
{
"error": "Validation failed"
}After (v3):
{
"errors": [
{
"code": "VALIDATION_ERROR",
"field": "email",
"message": "Email format is invalid",
"suggestion": "Use format: user@example.com"
},
{
"code": "VALIDATION_ERROR",
"field": "password",
"message": "Password too weak",
"suggestion": "Password must be at least 8 characters with uppercase, lowercase, and numbers"
}
]
}---
Enhanced Rate Limiting
New rate limit headers in every response:
HTTP/1.1 200 OK
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 950
X-RateLimit-Reset: 1642694400
X-RateLimit-Window: 3600
Retry-After: 3600Rate Limits by Plan:
| Plan | Requests/Hour | Burst | Reset |
|---|---|---|---|
| Free | 100 | 10/min | 1 hour |
| Pro | 1,000 | 50/min | 1 hour |
| Enterprise | 10,000 | 200/min | 1 hour |
---
✨ New Features
✨ New Features
Webhook Support
Subscribe to real-time events:
POST /api/v3/webhooks
Content-Type: application/json
{
"url": "https://your-app.com/webhook",
"events": ["user.created", "user.updated", "user.deleted"],
"secret": "your-webhook-secret"
}Webhook Payload:
{
"event": "user.created",
"timestamp": "2025-01-15T14:30:00Z",
"data": {
"id": "123",
"type": "user",
"attributes": {
"name": "John Doe",
"email": "john@example.com"
}
}
}Documentation: Webhook Guide
---
Batch Operations
Process multiple records in a single request:
POST /api/v3/users/batch
Content-Type: application/json
{
"operations": [
{
"method": "POST",
"path": "/users",
"body": { "name": "User 1", "email": "user1@example.com" }
},
{
"method": "PATCH",
"path": "/users/123",
"body": { "name": "Updated Name" }
},
{
"method": "DELETE",
"path": "/users/456"
}
]
}Response:
{
"results": [
{ "status": 201, "data": { "id": "789", ... } },
{ "status": 200, "data": { "id": "123", ... } },
{ "status": 204 }
]
}Limits: Maximum 100 operations per batch request
---
Field Filtering
Request only the fields you need:
GET /api/v3/users/123?fields=id,name,emailBefore (full response):
{
"data": {
"id": "123",
"type": "user",
"attributes": {
"name": "John Doe",
"email": "john@example.com",
"phone": "+1234567890",
"address": { "street": "123 Main St", "city": "NYC" },
"preferences": {
/* ... */
},
"metadata": {
/* ... */
}
// ... many more fields
}
}
}After (filtered response):
{
"data": {
"id": "123",
"type": "user",
"attributes": {
"name": "John Doe",
"email": "john@example.com"
}
}
}Benefits:
- Reduced response size (up to 80% smaller)
- Faster response times
- Lower bandwidth usage
---
🔒 Security
🔒 Security
- TLS 1.3 Required: Dropped support for TLS 1.2
- JWT Expiry: Tokens now expire after 1 hour (was 24 hours)
- Rate Limiting: Stricter limits on authentication endpoints
- CORS: Updated allowed origins (see security policy)
- Input Validation: Enhanced validation on all endpoints
---
🗑️ Deprecated
Deprecation Schedule
| Feature | Deprecated | Removal Date | Replacement |
|---|---|---|---|
| API Token Auth | v3.0.0 | 2025-06-01 | JWT Bearer tokens |
| XML Response Format | v3.0.0 | 2025-04-01 | JSON only |
/api/v1/* endpoints | v3.0.0 | 2025-03-01 | /api/v3/* |
Query param filter | v3.0.0 | 2025-05-01 | Use filters[field]=value |
Deprecation Warnings:
All deprecated features return a warning header:
HTTP/1.1 200 OK
Deprecation: true
Sunset: Sat, 01 Jun 2025 00:00:00 GMT
Link: <https://docs.example.com/migration/v2-to-v3>; rel="deprecation"---
📊 Version Support Policy
| Version | Status | Release Date | End of Support |
|---|---|---|---|
| v3.x | Current | 2025-01-15 | TBD |
| v2.x | Maintenance | 2024-01-01 | 2025-07-01 |
| v1.x | End of Life | 2023-01-01 | 2024-12-31 |
Support Levels:
- Current: Full support, new features
- Maintenance: Bug fixes and security patches only
- End of Life: No support, upgrade required
---
Step 1: Update Base URL
Step 1: Update Base URL
// Before
const API_BASE = "https://api.example.com/api";
// After
const API_BASE = "https://api.example.com/api/v3";Step 2: Migrate Authentication
// Before (v2) - API Token
const response = await fetch(`${API_BASE}/users`, {
headers: {
Authorization: `Token ${apiToken}`,
},
});
// After (v3) - JWT Bearer
const tokenResponse = await fetch(`${API_BASE}/auth/login`, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ email, password }),
});
const { token } = await tokenResponse.json();
const response = await fetch(`${API_BASE}/users`, {
headers: {
Authorization: `Bearer ${token}`,
},
});Step 3: Update Response Parsing
// Before (v2)
const user = await response.json();
console.log(user.name);
// After (v3) - Unwrap data object
const { data } = await response.json();
console.log(data.attributes.name);
// Or use SDK
import { ApiClient } from "@company/api-sdk";
const client = new ApiClient(token);
const user = await client.users.get("123");
console.log(user.name); // SDK handles unwrappingStep 4: Update Error Handling
// Before (v2)
try {
const response = await fetch(`${API_BASE}/users`);
if (!response.ok) {
const error = await response.json();
console.error(error.error);
}
} catch (error) {
console.error(error);
}
// After (v3) - Handle multiple errors
try {
const response = await fetch(`${API_BASE}/users`);
if (!response.ok) {
const { errors } = await response.json();
errors.forEach((err) => {
console.error(`${err.field}: ${err.message}`);
console.log(`Suggestion: ${err.suggestion}`);
});
}
} catch (error) {
console.error(error);
}Step 5: Update Pagination
// Before (v2)
const response = await fetch(`${API_BASE}/users?page=1&per_page=20`);
// After (v3)
const response = await fetch(`${API_BASE}/users?page[number]=1&page[size]=20`);
// Response structure
{
"data": [...],
"meta": {
"page": {
"current": 1,
"size": 20,
"total": 150,
"totalPages": 8
}
},
"links": {
"first": "/api/v3/users?page[number]=1",
"last": "/api/v3/users?page[number]=8",
"next": "/api/v3/users?page[number]=2",
"prev": null
}
}Step 6: Testing
// Run tests against v3 API
npm run test:api -- --api-version=v3
// Test migration gradually
const USE_V3 = process.env.USE_API_V3 === 'true';
const API_BASE = USE_V3
? 'https://api.example.com/api/v3'
: 'https://api.example.com/api/v2';---
#!/bin/bash
# validate-api.sh - Validate API specification
# Usage: ./validate-api.sh <openapi_spec>
set -euo pipefail
SPEC_FILE="${{1:?Usage: $0 <openapi_spec>}}"
echo "Validating API spec: $SPEC_FILE"
# TODO: Add API validation
# - Validate OpenAPI/Swagger syntax
# - Check endpoint naming conventions
# - Verify response schemas
# - Check for required headers
# - Validate authentication definitions
echo "API validation complete."
# API Endpoint Scaffold
# TODO: Customize for your API framework
openapi: "3.0.3"
info:
title: "API Service"
version: "1.0.0"
paths:
/api/v1/resource:
get:
summary: "List resources"
# TODO: Define parameters and responses
responses:
"200":
description: "Success"
post:
summary: "Create resource"
# TODO: Define request body and responses
responses:
"201":
description: "Created"
Related skills
FAQ
When should I use api-changelog-versioning?
api-changelog-versioning applies when adding or changing public API endpoints and response contracts. The skill designs semver bumps, deprecation notices, and changelog entries so API consumers understand breaking changes before release.
What artifacts does api-changelog-versioning produce?
api-changelog-versioning outputs semver versioning rules, deprecation notices for retiring endpoints or fields, and changelog entries documenting public API and response contract changes ready for release notes.