You are the person who owns the deployment pipeline. Your workflows push to AWS, Azure and Google Cloud without a single stored secret, and it has worked so quietly that you rarely think about why. Then a teammate asks you to add the environment to the OIDC subject so production can be told apart from a pull request, and you realize you are about to change something you have never looked at closely.
The GitHub Actions OIDC API is where that change lives. APIs.io lists 11 APIs for GitHub Actions with 82 operations between them, and this one has just 4, tied with Cache for the smallest surface in the set. The post calls it the most interesting API in the estate anyway, because those four operations decide what a cloud provider is actually trusting when it accepts a token from a workflow.
Here is what they do. The API reads and writes the template for the sub, or subject, claim in the OIDC tokens GitHub issues to workflow runs. It does this at two levels. You can GET or PUT the template for a repository, at /repos/{owner}/{repo}/actions/oidc/customization/sub, or for an organization, at /orgs/{org}/actions/oidc/customization/sub. That is getCustomOidcSubClaimForRepo, setCustomOidcSubClaimForRepo, getCustomOidcSubClaimForOrg and setCustomOidcSubClaimForOrg.
It looks like configuration trivia, and the post says it is not. Keyless deployment works because AWS, Azure, Google Cloud and the rest write trust policies that match on the subject claim. If the subject only says which repository a run came from, every branch and every environment in that repository gets the same cloud role. If your organization adds claim keys such as the environment or the job workflow reference, a trust policy can tell production from a pull request. The repo-level PUT can also take use_default and send a repository back to the stock template. That single write can widen what a cloud role accepts without anyone touching the cloud side.
One boundary matters for you. The token itself is not in this API. A runner requests it at job time, inside the job, and never through api.github.com. So this REST surface governs the shape of trust, not its issuance, and those are separate permissions.
Then the post turns to the record, including what it says against itself. The contract declares its base URL and exposes 9 JSON Schema definitions. The overview lists an OpenAPI specification, authentication docs, a getting-started guide, an API reference and a changelog. The provider scores 81.3, exemplar, with operational transparency at 97.4. Contract governance, at 31.8, is the weak facet. Agent Readiness is 50.0, agent-ready, but gated from agent-native.
There is also a caveat about credit. The conversational phrasing on each operation, two questions and two instructions apiece, was generated by API Evangelist on 2026-09-26. It is useful for routing, but it is the catalog's own work, not GitHub's. The humanURL points at the general Actions documentation rather than the OIDC reference, which the post calls its own pointer to fix.
If you hand this task to an agent, the post has a warning for you. The two PUTs are idempotent by HTTP semantics, but they are high-consequence writes. The record has no dry-run mode and no idempotency or reversibility documentation that applies to them. An agent asked to add the environment to your OIDC subject should first GET the current template, show you the diff, and remember that every cloud trust policy keyed to the old shape will stop matching the moment the PUT lands.
What you take away is practical. Before you change a subject template, read the current one, list the trust policies that depend on it, and treat the PUT as a change to every cloud that trusts you. And when you judge this API, look past its size. The post says what would improve it is better evidence, not more operations: a changelog entry for each claim key GitHub adds, an example payload for each level, and a documented warning in the contract that changing the template breaks existing trust policies. Four operations, and every downstream cloud depends on getting them right.
Read the original: https://apis.io/2026/10/21/github-actions-oidc-api-is-four-operations-that-decide-what-every-cloud-trusts/