Update Repo Variable returning 404

[ap3-sf]

Select Topic Area

Question

Body

We have a build task and we use the update repo varriable Rest Api endpoint to update a variable.
I am observing this one is failing for sometime. Unfurtunately I dont have details from when it failed as we were not taking builds that frequently and I dont have that much history to go back and refer to.

This was working fine earlier but now its goving me 404.
I have made sure request definitely is matching to the documentation and was working earlier.
https://docs.github.com/en/rest/actions/variables?apiVersion=2022-11-28#update-a-repository-variable

What are the possible reasons? Documentation does not have error details.

[rushikesh-bobade]

---

Hello!

Seeing a 404 Not Found on an endpoint that previously worked is a classic GitHub API "gotcha." As you noted, the documentation is sparse on errors, but in GitHub’s API design, a 404 often actually means "403 Forbidden." GitHub returns a 404 to prevent leaking the existence of private resources to unauthorized users.

Since your build process hasn't changed but the result has, here are the most likely reasons for this failure:

1. Token Expiration or Scope Change

This is the #1 culprit. If you are using a Personal Access Token (PAT), it may have expired or had its scopes modified.

• The Fix: Ensure your token has the repo scope (for classic PATs) or Repository permissions: "Variables" (Read & Write) for fine-grained tokens.
• Test: Run this command locally with your token to see if you can even "see" the variable:
  curl -H "Authorization: Bearer YOUR_TOKEN" https://api.github.com/repos/{owner}/{repo}/actions/variables/{variable_name}

2. The Variable Name is Case-Sensitive

GitHub Actions variables are case-sensitive in the API. If your build script recently changed MY_VARIABLE to my_variable in the URL string, the API will return a 404 because the exact resource name doesn't match.

3. Repository Renaming or Transfer

Did the repository or the Organization name change recently? If the repo was moved or renamed, the old URL might redirect for GET requests but fail with a 404 for PATCH requests used to update variables.

• The Fix: Hardcode the new repository path in your API string.

4. Base64 or Special Character Encoding

If your {variable_name} contains special characters or is being passed via a script variable that isn't being parsed correctly, the URL becomes invalid.

• The Fix: Check your logs (Step 62 in your image) to ensure the URL being called by curl is exactly what you expect.

5. "Variables" vs "Secrets"

Double-check that you are hitting the /variables endpoint and not the /secrets endpoint. Secrets use a different encryption workflow (requiring a public key) and will return errors if hit with a standard Variable PATCH request.

Recommended Debug Step:
To see the real reason GitHub is rejecting the request, add -i to your curl command in your build script:
curl -i -X PATCH ...
This will show you the X-Accepted-GitHub-Permissions and X-GitHub-SSO headers in the response, which will tell you exactly which permission your token is missing.

---

[Gecko51]

One thing worth adding to what's been said: if this is running inside a GitHub Actions workflow using the default GITHUB_TOKEN, that token can't update repository variables regardless of scopes. Updating variables via the API from within a workflow requires a PAT or a GitHub App token with the right permissions.

For fine-grained PATs, the specific permission you need is "Variables" (Read and Write) under Repository permissions. It's easy to miss because it's separate from the general actions scope.

Quick way to isolate the issue: run the call manually from your local machine:

curl -X PATCH \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"value":"test123"}' \
  https://api.github.com/repos/{owner}/{repo}/actions/variables/{variable_name}

If that returns 404 locally, the token is the problem. If it works locally but fails in CI, the workflow is using a different token than you think (check if you're accidentally reading the token from a secret that expired or was rotated). Also worth double-checking the variable name casing since the API is case-sensitive.

[ap3-sf]

this was my problem. I was not expecting it to be 404 result with a PAT issue.