LaunchDarkly API Version Migration Before the December 31, 2026 Retirement — when and how should I migrate?
Plan whether to keep older LaunchDarkly API integrations temporarily or migrate now to REST API version 20240415 before older API versions stop working.
Blockers
- Customers must use REST API version 20240415 starting January 1, 2027.
- protocol/rest-api-20220603 — EOL 2026-12-31
- breaking_change_in: protocol/rest-api → protocol/rest-api-20240415
- Generated REST clients should be upgraded to version 21.x or later.
- Lock-in via protocol/rest-api-20160426
Who this is for
- enterprise
- compliance
- low-ops
Candidates
Migrate now to REST API version 20240415
LaunchDarkly’s migration guide says customers must use REST API version 20240415 starting January 1, 2027, and the status page says older API versions retire on December 31, 2026. As of 2026-03-31, 20240415 is the current version and LaunchDarkly recommends explicitly setting the LD-API-Version header. Main breaking changes include pagination on more endpoints, removed filters on some list endpoints, removal of the compare parameter on list feature flags, and removal of deprecated Users and User settings APIs. Generated REST clients should be upgraded to version 21.x or later.
When to choose
Use this when the integration surface is broad, outage tolerance is low, compliance or change-control windows are tight, or you already have enough test coverage to validate endpoint and pagination changes now. It fits teams that want to avoid a late-2026 dependency audit and reduce risk from hidden usage of removed Users-era endpoints.
Tradeoffs
Pros: avoids a hard outage window in late 2026, aligns with LaunchDarkly’s recommended header-based version pinning, and restores supportability on the current API version. Cons: you must update pagination logic, remove deprecated filters and parameters, and replace any usage of removed Users-era endpoints.
Cautions
Check every integration for list endpoints that previously assumed one unpaginated response. Watch for list feature flags response changes, including the environments field only being returned when filtered by environment, and replace deprecated Users APIs with Contexts API equivalents where possible.
Keep older integrations temporarily, but only with a dated migration plan
As of 2026-03-31, older LaunchDarkly REST API versions may still work during the grace period, but the status page says that period ends on December 31, 2026 and retired versions will stop working after that. LaunchDarkly’s docs also say version 20220603 reaches end of life on December 31, 2026 for actual access and that customers must move to 20240415. This is a short deferral for inventory, testing, and phased rollout, not a steady-state option.
When to choose
Use this only if a near-term migration is blocked by change freezes, critical release windows, or large unknown dependency chains. The decisive condition is having a concrete migration backlog, test plan, and owner before mid-2026 rather than treating the grace period as a safe permanent state.
Tradeoffs
Pros: minimizes immediate engineering churn and lets teams sequence endpoint audits and library upgrades carefully. Cons: preserves deadline risk, increases the chance of missing hidden dependencies, and compresses remediation into a narrower window later in 2026.
Cautions
Do not assume access token version pinning is enough for long-term safety; LaunchDarkly recommends explicitly setting the LD-API-Version header in clients and integrations. Inventory old tokens too, because tokens created before versioning can still be pinned to very old behavior, including 20160426-era semantics.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "LaunchDarkly API Version Migration Before the December 31, 2026 Retirement — when and how should I migrate?"