Thanks francisfuzz. Yes, this sort of helps. mergeable_state==“BLOCKED” is indeed what I was looking for. I was just confused because it is not part of the documented API. I guess the chances are small that the possible values will change incompatibly, no that the v4 API is more or less cementing the same.

This seems relevant: docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests

Warning! Please do not depend on using Git directly or GET /repos/{owner}/{repo}/git/refs/{ref} for updates to merge Git refs, because this content becomes outdated without warning.

A consuming API needs to explicitly request a pull request to create a test merge commit. A test merge commit is created when you view the pull request in the UI and the "Merge" button is displayed, or when you get, create, or edit a pull request using the REST API. Without this request, the merge Git refs will fall out of date until the next time someone views the pull request.

If you are currently using polling methods that produce outdated merge Git refs, then GitHub recommends using the following steps to get the latest changes from the default branch:

Receive the pull request webhook.
Call GET /repos/{owner}/{repo}/pulls/{pull_number} to start a background job for creating the merge commit candidate.
Poll your repository using GET /repos/{owner}/{repo}/pulls/{pull_number} to see if the mergeable attribute is true or false. You can use Git directly or GET /repos/{owner}/{repo}/git/refs/{ref} for updates to merge Git refs only after performing the previous steps.