API Versioning Strategy

Produce a complete API versioning strategy document that gives a service team durable, consistent rules for evolving their API without breaking consumers. This document covers the versioning scheme selection (with rationale), lifecycle policy from introduction through sunset, a precise breaking-change classification, and all the communication artifacts a team needs when deprecating a version. Engineers should be able to hand this document to a new team member or external consumer and have them understand exactly what to expect.

Required Inputs

Ask for these if not already provided:

• API type — REST, GraphQL, or gRPC (each has different versioning mechanics)
• Current versioning approach — URL path (/v1/), request header, query parameter, or none; if none, document starts fresh
• Number of existing versions and active consumer count — needed to size the lifecycle policy and migration scope
• Deprecation timeline constraints — any hard deadlines (contract SLAs, compliance windows, annual release cycles)
• Consumer type — internal teams only, external partners, public API, or mix (affects communication channel choices)

If any input is missing, ask before producing the document. For GraphQL, note that the versioning approach differs substantially (schema evolution over versioning) and tailor the scheme section accordingly.

Output Format

API Versioning Strategy: [Service Name]

Owner: [Team Name] API Type: [REST / GraphQL / gRPC] Document Version: 1.0 Last Reviewed: [Date] Next Review: [Date + 6 months]

1. Versioning Scheme

Selected Approach: [URL Path / Request Header / Query Parameter]

Rationale for [chosen scheme]: [One paragraph explaining why this scheme fits the API type, consumer type, and operational context provided. Reference the specific inputs — e.g., "Because this API has external partners who integrate via generated clients, URL path versioning provides the most predictable routing behavior and eliminates header negotiation complexity."]

Version Format

[Base URL]/v{MAJOR}/{resource}

Examples:
  https://api.[company].com/v1/orders
  https://api.[company].com/v2/orders/{id}/items

Version identifier: integer only (v1, v2, v3)
No minor versions in the URL — minor/patch changes are non-breaking and deployed continuously.

2. Version Lifecycle Policy

Lifecycle Stages

  STABLE ──────────────────────────────────────────────────►
      │
      ├─ STABLE        Active development, full SLA, new consumers allowed
      │
      ├─ DEPRECATED    Announced, timeline posted, migration docs live.
      │                New consumers blocked. Existing consumers receive warnings.
      │
      ├─ SUNSET        Requests return HTTP 410 Gone + migration pointer.
      │                30-day window before routing is removed.
      │
      └─ RETIRED       Routing removed, docs archived, no traffic accepted.

Minimum Stable Period: A version must remain Stable for at least [6 / 12] months before deprecation can be announced.

Maximum Simultaneous Versions: No more than [2] versions in Stable or Deprecated status at any time. Releasing v3 requires committing to a sunset date for v1 in the same announcement.

3. Breaking vs. Non-Breaking Change Classification

Apply this table before every API change. If a change is marked Breaking, it requires a new major version. When uncertain, default to Breaking.

4. Deprecation Process

Step-by-Step Deprecation Checklist

• T-0 (Decision day): Engineering lead approves deprecation. New version confirmed Stable. Sunset date set.
• T-0: Update API docs — add deprecation banner to all v[N] endpoint pages.
• T-0: Add Deprecation and Sunset response headers to all v[N] responses (see format below).
• T-0: Block new consumer onboarding for v[N] in API gateway and developer portal.
• T-0: Send initial deprecation notice to all registered consumers (see Section 5 template).
• T-0: Open tracking issue in engineering backlog linking all known consumers to their migration status.
• T minus 30 days: Send 30-day warning to all consumers still sending v[N] traffic.
• T minus 7 days: Send final warning. If consumer traffic > 100 req/day, escalate directly to their engineering lead.
• Sunset date: Switch v[N] routing to return HTTP 410 Gone with body pointing to migration guide.
• T plus 30 days: Remove routing rules. Archive documentation. Close tracking issue.

Deprecation