GitHub Actions publishes 11 APIs on apis.io with 82 operations between them. The GitHub Actions OIDC API has 4 of them, tied with Cache for the smallest surface in the set. It is still the most interesting API in the estate, because those four operations decide what a cloud provider is actually trusting when it accepts a token from a workflow.
What the four operations do
The API does one thing. It reads and writes the template for the sub (subject) claim in the OIDC tokens GitHub issues to workflow runs, at two levels.
| Operation | Method | Scope |
|---|---|---|
| getCustomOidcSubClaimForRepo | GET | /repos/{owner}/{repo}/actions/oidc/customization/sub |
| setCustomOidcSubClaimForRepo | PUT | /repos/{owner}/{repo}/actions/oidc/customization/sub |
| getCustomOidcSubClaimForOrg | GET | /orgs/{org}/actions/oidc/customization/sub |
| setCustomOidcSubClaimForOrg | PUT | /orgs/{org}/actions/oidc/customization/sub |
That looks like configuration trivia, and 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 an 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 is a single write that can widen what a cloud role accepts without anyone touching the cloud side.
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 the REST surface governs the shape of trust, not its issuance, and those are separate permissions.
What the record shows
The contract declares its base URL (https://api.github.com) 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, gated from agent-native.
There is one 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 ours, not GitHub’s. The humanURL points at the general Actions documentation rather than the OIDC reference, which is our pointer to fix.
Why an agent should be careful here
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 our OIDC subject” should first GET the current template, show the diff, and remember that every cloud trust policy keyed to the old shape will stop matching the moment the PUT lands.
Takeaway
What would move this API is better evidence, not more operations. That means 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.
See the API at apis.io/apis/github-actions/github-actions-oidc-api/.