What Just ChangedAPI changes
API change record

GitHub REST API 2026-03-10 versioning

Reviewed August 10, 2026Evidence confidence: Official GitHub REST API docsPrimary domain: REST integrations / version pinning
Current decisionIntegrations should send X-GitHub-Api-Version explicitly, read the breaking-change notes before upgrading, and test against the target version rather than relying on unversioned defaults.

What changed?

GitHub's REST API is date-versioned. GitHub documentation lists API version 2026-03-10 and describes breaking changes as changes that can potentially break an integration. GitHub also says the previous API version is supported for at least 24 months after a new REST API version is released.

Who is affected?

This matters for apps, bots, CI systems, automations, and internal tools that call the GitHub REST API, especially if they rely on default behavior or hard-code assumptions about response fields, parameters, enum values, validation rules, or rate-limit fields.

What can break?

  • A deprecated response field can be removed in a newer API version.
  • Requests specifying an unsupported version can receive 410 Gone.
  • Unversioned requests can shift behavior when old versions leave support.
  • Integrations can fail if they upgrade the header but do not update code for the new version.

Smallest safe migration

  1. Inventory all REST clients and whether they send X-GitHub-Api-Version.
  2. Read the breaking-change section for the target API version.
  3. Update field reads, parameters, validation, and rate-limit handling if needed.
  4. Test real requests in staging or against non-critical repositories.
  5. Monitor responses for Deprecation, Sunset, and 410 Gone.

Official sources

Independent research, not official GitHub support. Verify your own API headers, token permissions, and integration behavior before upgrading production tooling.