GitHub releases REST API version 2026-03-10

GitHub published REST API version 2026-03-10 on March 12, creating a new explicit contract for integrations that call the platform over HTTP. The official changelog tells clients to select it with the X-GitHub-Api-Version request header and points maintainers to a breaking-changes guide.

A version boundary teams can test

Dated API versions matter because they separate adoption from the day GitHub changes its default behavior. An integration can keep its existing header while engineers run the new contract through tests and staging. That makes the migration unit concrete: inventory requests, compare response fields and validation rules, then change one declared version instead of relying on an undocumented rollout date.

The announcement does not say every endpoint changed. Teams should use GitHub’s linked change list to identify the endpoints they actually call. Generated clients, webhook consumers, and GraphQL integrations also need separate treatment; this notice is specifically about the REST API.

What maintainers should check

Start by finding every place the version header is set: shared HTTP wrappers, command-line scripts, infrastructure jobs, and vendor connectors can diverge. Capture representative successful and failing responses before upgrading, especially for code that treats an absent field differently from null or passes enum values through without validation.

Roll the header change with request telemetry that records endpoint and status class without logging credentials or sensitive payloads. If several services share one GitHub app, deploy independently where possible so a regression can be isolated. Finally, pin the chosen version in examples and runbooks. The value of a dated contract disappears when production code silently falls back to a platform default.