Pimp My IDE / garage dispatch
Back to garage
October 1, 2026 | automation / merge queues

Accepted is not merged.

GitHub's async merge API moves merge work into the background. Your automation now needs to keep the request receipt, read the result, and verify the pull request after a queue accepts it.

A 202 response means GitHub accepted work. An enqueued result means the queue accepted a pull request. Only a merged result or a later merged-state check proves the merge.

The merge call now starts a job.

GitHub made its asynchronous merge API generally available on October 1. The endpoint can merge one pull request, process a stack, or place a pull request in a merge queue. GitHub now recommends it over the synchronous REST endpoint and GraphQL merge mutations for programmatic merges.[1]

The request uses PUT /repos/{owner}/{repo}/pulls/{pull_number}/merge-async. A new background request returns HTTP 202 and a UUID. A later GET uses that UUID to fetch the result.[2]

The first response proves that work entered the system. It does not prove that code entered the branch.

Enqueued is a handoff, not a finish line.

The result endpoint reports pending, merged, enqueued, or failed. GitHub's documentation is explicit about the queue case. An enqueued result is final for the async request, but it does not change after the queue later merges the pull request. The client must check the pull request's eventual merged state separately.[2]

That boundary belongs in the interface. Do not turn the first green response into a "Merged" toast. Show "Request accepted" for 202. Show "Queue entry confirmed" for enqueued. Reserve "Merged" for a merge commit object ID or a later endpoint that says the pull request merged.

Pin the head before you hand it over.

The async endpoint accepts a head SHA. If the pull request changes between the request and execution, GitHub cancels the merge. If the client omits the SHA, GitHub uses the current head at request time. Save that expected SHA in the receipt so a reviewer can tell which candidate entered the lane.[2]

The endpoint also accepts a merge action and a rules-bypass flag. A default action may use a configured merge queue or merge directly. Bypass remains false unless the caller requests it and has permission. Put both values in the receipt. A result without the requested route and bypass choice is hard to audit.

Poll the job, not the whole garage.

GitHub says API clients should prefer webhooks to broad polling. If polling is necessary, clients should use a fixed schedule, honor x-poll-interval, make conditional requests, and request only needed data.[3] The async result record expires 24 hours after its most recent update, so retain the result before that window closes.[2]

A practical loop is small. Submit once. Save the UUID and expected SHA. Poll that UUID until the async result leaves pending. If it says enqueued, switch to the pull request's merged-state check or a relevant webhook. Save the final commit object ID or the failure message.

Interactive makeover / merge receipt dock

Park the receipt in the right bay

Traditional purpose replaced: one success toast after a merge API call. Better version: select the observed result, see what it proves, get the next check, and copy a receipt that keeps unknown values visible.

Select the observed result

This teaching tool formats a review receipt. It does not call GitHub or verify a repository.

API state

Typed values change the receipt only. A completed-looking card does not verify a live merge.

Async merge / receipt route

Merge carriage

Pending / wait

Request accepted. Merge not proved.

Poll the result endpoint with the saved UUID. Keep the expected head SHA beside it.

Four bays / four meanings

Give each response one honest label.

01 / PENDING

Work is running

Keep the UUID and expected head SHA. Poll the request result on a bounded schedule.

02 / ENQUEUED

The queue has it

Switch to a pull request merged-state check or webhook. The queue receipt is not a merge receipt.

03 / MERGED

Save the commit

Retain the merge commit object ID and the candidate SHA that the request expected.

04 / FAILED

Keep the reason

Save the failure message. Do not hide a cancelled or rejected candidate behind a generic retry.

Sources read

Source log and evidence boundary
  1. GitHub Changelog, "GitHub async merge API generally available", published and read October 1, 2026. GitHub says the async API is generally available, supports direct, queued, and stacked pull request merges, and is the recommended programmatic merge route.
  2. GitHub REST documentation, "Merge a pull request asynchronously" and "Get the result of an asynchronous merge", read October 1, 2026. The documentation defines response codes, request fields, result states, the enqueued boundary, and the 24-hour retention window.
  3. GitHub REST documentation, "Best practices for using the REST API", read October 1, 2026. GitHub recommends webhooks over polling and lists fixed schedules, poll headers, conditional requests, and small responses for clients that must poll.
  4. Hacker News front page, fetched through the official API on October 1, 2026. It was scanned with current release feeds during topic selection. It is a discovery source, not evidence for the GitHub API claims.

Evidence boundary: GitHub documents the API and its result meanings. The receipt format, dock labels, and interface guidance are Pimp My IDE editorial recommendations. We did not submit a merge request because that would require a repository, pull request, and write credential.