GitHub API version 2026-03-10 drops merge_commit_sha from PR responses

What changed

GitHub's REST API version 2026-03-10 no longer includes the merge_commit_sha field in pull request payloads. According to a post on dev.to, originally published on the DriftSignal blog, the field is gone from every endpoint that returns a pull request, covering single-PR reads, PR lists, and events.

Nothing at runtime signals the removal. Endpoints keep answering with HTTP 200 and well-formed JSON, so code that reads the field to learn which commit a merged PR landed as receives null or undefined instead of an exception, and the automation keeps running as if the data were still there.

Where the failure shows up

Because nothing throws, the damage surfaces downstream. The post's examples: a deployment that ships the wrong commit, a changelog generator that emits garbage, or a bot that comments with a SHA that no longer exists. The gap between the version bump and the visible symptom can stretch across days or weeks, usually long enough that nobody connects the two.

Other quiet removals in the same version

Reviewing the 2026-03-10 breaking changes, the post finds that most of them stay invisible at runtime:

• The singular assignee field is removed from Issues and Pull Requests. It duplicated the assignees array and had been on the way out for years, but older integrations still reading issue.assignee now get nothing — a triage bot checking the singular field would decide every issue is unassigned.
• has_downloads disappears from Repository responses after more than a decade of deprecation. Code branching on it takes the wrong branch without complaint.
• In code scanning setup responses, the javascript and typescript language values are replaced by a single javascript-typescript value. Equality checks and switch statements written against the old enum simply stop matching.
• cvss is deprecated in favor of cvss_severities across the advisory and Dependabot alert APIs, with severity data moving into a new nested shape. The post calls this especially risky, since security workflows reading the old path now see null severities.
• Leftovers from a beta media type rename keys — user becomes owner, master_branch becomes default_branch. Parsers do not throw; they just stop finding values under the names they were built around.

The post also mentions some status code changes and a couple of endpoints that now hand work off to background processing.

Pinning the version only postpones the problem

GitHub dates its API versions and lets clients opt in via the X-GitHub-Api-Version header, and the post recommends pinning that header rather than letting it float. But it argues pinning is a delay tactic, not a fix, for three reasons.

First, GitHub supports a previous version for at least 24 months after a new one ships, so every pin carries a countdown rather than a permanent answer.

Second, pinning protects against versioned breaking changes only. Behaviour can drift between versions — defaults shift, fields that were always populated come back empty in edge cases — and none of that waits for a dated release.

Third, the day you do bump the pin, nothing fails loudly. Code compiles, tests pass, the API returns success, and the fields you stopped receiving are exactly the ones your tests never asserted on, because they test the contract you assume the new version has.

Recommended checks

Whether or not a team has already moved to 2026-03-10, the post prescribes the same defenses: validate responses against a schema at the system boundary so a missing field raises an error instead of flowing through as null; assert on the payload values you depend on, not just status codes; diff a real response from the old version against the same request on the new version before switching; and repeat that check on a schedule, since the next version is already in the works.

One caveat worth stating: DriftSignal sells tooling that monitors live APIs against their OpenAPI specs, so the post has a commercial interest in this framing. The field removals it describes are still the kind of change worth verifying against GitHub's own changelog regardless.

Why it matters

By the post's own account, GitHub is the conscientious example here — dated versions, a published changelog, a long support window. Even so, the breaking change arrives as a field vanishing from a successful response, with the failure surfacing later inside someone else's pipeline. Any deployment script, release tool, or bot that consumes GitHub PR data should search for the removed fields now, starting with merge_commit_sha, because nothing at runtime will announce the breakage. And if a carefully versioned API can fail this quietly, the unversioned third-party APIs most systems also depend on can do the same with far less warning.