GitHub makes its async merge API generally available, and it is the only one that handles stacked pull requests

Merging a pull request from a bot has been one of the quieter ways CI jobs time out. The synchronous REST endpoint keeps the HTTP connection open until the merge finishes, and on a repository with contested branches that wait can last several minutes. Stacked pull requests had no merge API of their own at all.

GitHub moved its async merge API to general availability on 1 October 2026. A bot now submits a merge with a PUT request, gets a request ID back, and polls a GET endpoint until the status says the merge is done. GitHub's own announcement calls this "the recommended path for programmatically merging pull requests" and names two older paths it replaces: the synchronous REST endpoint and the GraphQL merge mutations.

What the one endpoint covers

The same API handles four cases GitHub names in the changelog: merging an individual pull request, merging a chain of stacked pull requests, adding a pull request to a merge queue, and merging a pull request directly. GitHub also says the endpoint can optionally bypass branch rules when the caller has permission to do so. That matters for merge queues and automated release scripts, which have to clear protection rules without a person clicking approve.

The stacked-pull-request line is the real new capability. The company writes it plainly: this is "the only merge API that supports stacked pull requests." A team that uses tools like Graphite or ghstack has, until today, had to click merge in the UI for each layer of a stack, or point their automation at the UI because no API existed.

The shape of the call

The async part is the useful part on a busy repository. The sync endpoint holds the HTTP request open until GitHub finishes checking required status, mergeability and branch rules; a client that times out at thirty seconds will give up on a merge that eventually succeeds and have no clean way to tell. The async API returns a request ID the moment the merge is accepted, and the caller polls the GET endpoint with that ID to read the state.

A bot that currently runs retry loops around the sync endpoint can remove them: the polling pattern GitHub documents is the pattern the retry loops were trying to approximate. GitHub points callers at its async merge API documentation for parameters and worked examples, and the changelog is tagged under "collaboration tools."

The design choice this closes is a small one for a human merging a single pull request through the UI, and a large one for every piece of software that merges pull requests for a human. A merge queue is the obvious example; so is a bot that merges dependency updates, and so is a release pipeline that merges a chain of stacked refactors in order. All three have had to work around a merge endpoint that behaves like a long-running job but was shaped for a short request. From today they can call an endpoint that matches the work.

Source

Primary source: GitHub async merge API generally available, GitHub Changelog, 1 October 2026.