Thanks for posting in the GitHub Community, @akpay !

We're happy you're here. You are more likely to get a useful response if you are posting your question in the applicable category, the Issues category is solely related to conversations around the GitHub products Issues and Projects. I've gone ahead and moved it for you. Good luck!

@queenofcorgis
I have the same issue with a POST /refs call (Create a reference). Sometimes it works, sometimes it fails with HTTP 422 and ´message`propety: 'Reference update failed'. This message is as generic as it can get and is not helpful. No offense, but we would not accept such error messages from our own developers. Actions log of a recent occurrence: https://github.com/zhmcclient/zhmc-log-forwarder/actions/runs/15422025589/job/43399389633

It seems to me that the HTTP status 422 is also used for rate limit issues (i.e. the "the endpoint has been spammed" part of the explanation).

I searched for "HTTP 422" in the documentation and got this response:

HTTP 422 (Unprocessable Entity) typically occurs when the server understands the request but cannot process it due to semantic errors. If you're encountering this error while using GitHub's REST API, it could be due to invalid or missing data in your request.

Here are some common causes and troubleshooting steps:

• Check the Request Body: Ensure that the JSON payload in your request is correctly formatted and includes all required fields. For example, when creating a repository, ensure fields like name are provided.
• Validate Input Data: Verify that the values you are sending match the expected data types and constraints. For instance, if you're using the /repos endpoint, ensure the repository name doesn't contain invalid characters.
• Authentication and Permissions: Confirm that your access token or authentication method has the necessary permissions for the action you're trying to perform. For example, creating a repository requires repo scope.
• Endpoint-Specific Requirements: Review the documentation for the specific endpoint you're using to ensure all required parameters are included. For example, for artifact attestations, ensure the payload matches the expected format.
• Error Message Details: The response body of the 422 error often contains details about what went wrong. Check the error message for clues about missing or invalid fields.

If you need more information about specific endpoints, you can refer to the documentation:

On "Check the error message for clues about missing or invalid fields": Unfortunately, the message property is not very helpful, as explained above. Also, this response does not even mention the case of "the endpoint has been spammed".

Searching for "what does HTTP 422 error mean in the GitHub rest api?" results in this response:

The HTTP 422 error in the GitHub REST API means "Validation failed, or the endpoint has been spammed." This typically occurs when the parameters provided in the request are invalid or do not meet the requirements of the API endpoint.

To troubleshoot this error:

• Review the documentation for the specific endpoint you are using to ensure all required parameters are included and correctly formatted.
• Check if any unique constraints (e.g., unique names for resources) are being violated.
• If the error persists, refer to the message property in the API response for more details about the issue.

For more information, see: https://docs.github.com/en/rest/using-the-rest-api/troubleshooting-the-rest-api

This response again refers to the not very helpful message property in the response.

I would appreciate if someone from GitHub could comment on this issue and provide some explanation about the cause of HTTP 422, and some guidance on how to deal with it when causes such as an invalid request can be excluded. No offense, but this issue now has been open for 2.5 years...

Update: I checked the branch protection settings of the repo, and it turned out that "Restrict pushes that create matching branches" was enabled for the respective branch protection rule, without any users specified. I thought this might be the reason for the 422 error and disabled it, but a test workflow to verify that succeeded in creating a branch, with and without that setting enabled. So the occurrence of the HTTP 422 in this case does not seem to depend on that setting. Log when setting was enabled: https://github.com/zhmcclient/zhmc-log-forwarder/actions/runs/15432877962

Update 2: I opened issue github/rest-api-description#4887