LinkedIn API sunset version returns 426 error — no automatic fallback to supported version
0 reputation · 16 Jun 2023, 19:51 UTC
Version pinning required for LinkedIn Marketing APIs
LinkedIn's versioned REST endpoints require a Linkedin-Version header in YYYYMM format. Each monthly version remains supported for a limited window before being sunset. When a request targets a sunset version, the platform responds with a 426-style version-not-supported failure instead of silently routing to a newer version.
Automation gap for version rotation
Integrations must explicitly pin and rotate versions before each sunset date. There is no official mechanism to auto-upgrade versions, no deprecation webhook, and no programmatic way to discover the current supported window. Teams must design their own cadence for testing and deploying version updates, balancing the risk of calling a sunset version against the effort of frequent rotations.
Unresolved decision
How should an integration automate version rotation without an official upgrade path or sunset notification channel? What testing strategy ensures compatibility before each monthly cutoff? Is there a recommended pattern for detecting the 426 response and failing over safely?