Agent report card
Can an agent use GitHub REST API through Repository operations?
Five-stage assessment
Where agent autonomy holds and where it breaks
- EvaluateReady
- Sign upReady
- PayReady
- ProvisionLimited
- OperateLimited
The exact service and stable evaluation or access entrypoints are publicly discoverable.
The GitHub REST API and its documentation entrypoints are publicly discoverable, including versioning details and getting started documentation.
Applicable terms are stable, readable, retrievable, and materially complete.
Eligibility conditions and required inputs are explicit and decidable.
Price or no-charge status, variables, currency, and material conditions are explicit.
Verified structured artifacts accelerate discovery of the evaluation surface.
Evidence and actions6 signals
Can an agent decide every material eligibility condition before commitment?
supported: freshEligibility conditions and required inputs are explicit and decidable.
GitHub's Terms of Service state explicit eligibility requirements and inputs, such as requiring a valid email address and requiring users to be at least 13 years old (or older if required by local law). Usage is also subject to export control and sanctions laws.
Can an agent estimate cost or confirm no-charge status before commitment?
supported: freshPrice or no-charge status, variables, currency, and material conditions are explicit.
GitHub's pricing page explicitly states plan costs and conditions, such as $0 USD per month forever for the Free plan and $4 USD per user/month for the Team plan. Variable compute and storage fees for Codespaces and Git LFS are also explicitly disclosed in USD.
Can an agent find the exact service and its stable entrypoints?
supported: freshThe exact service and stable evaluation or access entrypoints are publicly discoverable.
The GitHub REST API and its documentation entrypoints are publicly discoverable, including versioning details and getting started documentation.
Are verified structured discovery artifacts available?
supported: freshVerified structured artifacts accelerate discovery of the evaluation surface.
GitHub explicitly documents that the REST API is fully described in an OpenAPI compliant document.
Can an agent retrieve and understand the applicable commitment terms?
supported: freshApplicable terms are stable, readable, retrievable, and materially complete.
The GitHub Terms of Service are readable, retrievable, and complete, detailing account terms, acceptable use, definitions, and legal agreements.
Does the vendor deliberately describe access for web agents?
supported: freshCurrent admissible evidence does not resolve this finding.
The retained evidence from the API versions and REST API documentation does not contain explicit declarations or policies regarding web agent or crawler access rules.
A stable canonical route begins the required access bootstrap.
Documentation explicitly directs users to https://github.com/signup as the canonical route to sign up for a personal account.
Scoped revocable credentials or delegated authorization have explicit consent and resumption boundaries.
Evidence and actions5 signals
Can an agent operate the access controls and safe handoffs deterministically?
supported: freshCurrent admissible evidence does not resolve this finding.
The signup endpoint returned an unresolved 403 response requiring JS, leaving access control operability unresolved.
Is there a stable route to begin obtaining service access?
supported: freshA stable canonical route begins the required access bootstrap.
Documentation explicitly directs users to https://github.com/signup as the canonical route to sign up for a personal account.
Can an agent obtain access without an unsupported CAPTCHA boundary?
supported: freshCurrent admissible evidence does not resolve this finding.
The direct signup endpoint returned an HTTP 403 error page, and documentation does not establish whether a CAPTCHA boundary exists during registration.
Can an agent obtain scoped, revocable authority for this service?
supported: freshScoped revocable credentials or delegated authorization have explicit consent and resumption boundaries.
GitHub Apps support generating user access tokens with fine-grained permissions via OAuth web application or device authorization flows, and tokens can be explicitly revoked by users or application owners.
Can required phone verification be completed through a supported boundary?
supported: freshCurrent admissible evidence does not resolve this finding.
The signup endpoint returned an HTTP 403 error page, and documentation only specifies email verification during account creation without addressing phone verification.
Charge or no-charge status, currency, recurrence, and material conditions are disclosed.
GitHub explicitly discloses its pricing plans, charge status ($0 USD/month for Free), currency (USD), recurrence (monthly/yearly), and billing impact rules such as immediate prorated billing for plan upgrades and seat additions.
A documented direct purchase path reaches paid access without a vendor decision point.
Evidence and actions4 signals
Can an agent construct checkout, hand off approval safely, and resume?
supported: freshCurrent admissible evidence does not resolve this finding.
The retained evidence describes UI steps to upgrade account plans and select payment methods, but does not state or establish deterministic checkout construction, approval handoff, and resumption mechanisms for an agent.
Is the exact commercial commitment disclosed before authorization?
supported: freshCharge or no-charge status, currency, recurrence, and material conditions are disclosed.
GitHub explicitly discloses its pricing plans, charge status ($0 USD/month for Free), currency (USD), recurrence (monthly/yearly), and billing impact rules such as immediate prorated billing for plan upgrades and seat additions.
Can payment be authorized within scoped agent or explicit human authority?
supported: freshCurrent admissible evidence does not resolve this finding.
While documentation lists payment method steps like credit card or PayPal submission, the retained evidence does not define a payment authorization rail with scoped delegation or explicit human confirmation with receipts.
Is a direct self-service path to paid access documented?
supported: freshA documented direct purchase path reaches paid access without a vendor decision point.
GitHub documents a direct self-service path to upgrade personal accounts to GitHub Pro or organization accounts to GitHub Team/Enterprise via account billing settings without requiring a vendor decision point.
Delivery needs additional human transfer or has weak scope or lifecycle semantics.
GitHub REST API documentation describes creating personal access tokens and generating user access tokens or client secrets via app settings. Delivering credentials through manual UI creation or OAuth exchange flows involves human transfer or web/device authorization handoffs.
Provisioning is machine-triggerable or follows deterministically from an allowed handoff.
A synchronous success response returns a usable created resource or access material; otherwise asynchronous work exposes progress, terminal state, reconciliation, and a documented bound.
Evidence and actions3 signals
Can usable access material be delivered securely to an authorized agent?
supported: freshDelivery needs additional human transfer or has weak scope or lifecycle semantics.
GitHub REST API documentation describes creating personal access tokens and generating user access tokens or client secrets via app settings. Delivering credentials through manual UI creation or OAuth exchange flows involves human transfer or web/device authorization handoffs.
Can an agent determine successful provisioning completion and reconcile asynchronous failure?
supported: freshA synchronous success response returns a usable created resource or access material; otherwise asynchronous work exposes progress, terminal state, reconciliation, and a documented bound.
Creating a repository returns a synchronous 201 Created HTTP response status code with the created repository object.
Can provisioning be initiated within supported agent authority?
supported: freshProvisioning is machine-triggerable or follows deterministically from an allowed handoff.
Provisioning repository resources can be initiated directly via POST HTTP requests to the REST API endpoints (/orgs/{org}/repos and /user/repos).
What would improve this stage
- Deliver scoped access material through a secure documented machine-usable flow.
Safe failure handling is documented only partially.
Troubleshooting documentation defines status codes, rate limit error handling (using x-ratelimit-remaining, x-ratelimit-reset, and retry-after headers), exponential backoff for retries, timeouts, and JSON validation errors, but idempotency, cancellation, and reconciliation semantics are not fully established.
Only part of the credential lifecycle is agent-operable.
Every essential target has a stable documented agent-usable interface alternative.
Request-time authentication is documented and usable under scoped agent authority.
Essential operations have stable readable request, response, and effect semantics.
Evidence and actions6 signals
Is an agent-native protocol interface verified against the essential targets?
supported: freshCurrent admissible evidence does not resolve this finding.
The retained evidence mentions an OpenAPI description for the REST API, but it does not establish a verified agent-native protocol interface such as MCP or A2A for the assessment targets.
- repository-api
Can an agent manage credential expiry, rotation, revocation, compromise, and recovery?
supported: freshOnly part of the credential lifecycle is agent-operable.
The documentation establishes token expiration, token refresh via refresh tokens, and token revocation via the credential revocation API, but complete agent-operable credential recovery and lifecycle automation across all credential types remain unevidenced.
Can an agent handle applicable failure modes safely?
supported: freshSafe failure handling is documented only partially.
Troubleshooting documentation defines status codes, rate limit error handling (using x-ratelimit-remaining, x-ratelimit-reset, and retry-after headers), exponential backoff for retries, timeouts, and JSON validation errors, but idempotency, cancellation, and reconciliation semantics are not fully established.
Can an agent authenticate service operations with scoped authority?
supported: freshRequest-time authentication is documented and usable under scoped agent authority.
Request-time authentication is documented using personal access tokens, GitHub App access tokens, or GITHUB_TOKEN passed in the Authorization header as Bearer or token.
Are essential operation inputs, outputs, and effects stable and decidable?
supported: freshEssential operations have stable readable request, response, and effect semantics.
The essential operations across the rate-limits, repository-operations, rest-api, and troubleshooting targets have documented HTTP methods, path/query parameters, request/response headers, status codes, schemas, and error structures.
- repository-api
Can an agent perform every essential assessment target through a usable interface?
supported: freshEvery essential target has a stable documented agent-usable interface alternative.
Documented usable HTTP REST API endpoints and code examples exist for every essential target surface in the scope.
- repository-api
What would improve this stage
- Document applicable structured errors, retry, cancellation, and reconciliation semantics.
- Provide scoped expiry, rotation, revocation, compromise, and recovery operations.
What works
- Evaluate: The exact service and stable evaluation or access entrypoints are publicly discoverable.
- Sign up: A stable canonical route begins the required access bootstrap.
- Pay: Charge or no-charge status, currency, recurrence, and material conditions are disclosed.
What blocks agents
No stage is established as blocked.
Where autonomy is limited
- Provision: Delivery needs additional human transfer or has weak scope or lifecycle semantics.
- Operate: Safe failure handling is documented only partially.
What this grade establishes
14 of 14 graded signals have current supporting evidence. 0 of 5 additional barrier checks are verified.Unknown checks are not a pass or a confirmed blocker. This report is not proof of an end-to-end purchase or service session.
How the grade is derived
A through C grades count Limited stages; D and F reflect Blocked stages by lifecycle severity.
Coverage is complete only when every graded signal has supported, fresh, non-conflicting evidence. Barrier and informational signals do not change coverage; only fresh, supported barrier values that passed their admission evidence rule participate in stage outcomes.
Each stage takes its worst graded signal or verified barrier. A fresh, supported mandatory barrier that passed its admission evidence rule can block that stage; incomplete or stale barrier evidence remains context only. The overall grade is derived from the five stage states.
Startup offers
GitHub on the startup-offers board
- $10,000 in creditsGitHub for Startups Offer
Distribution
The grade’s badge
One stable image resolving the record’s current live facts, linking to the canonical page. Embed it once; it keeps itself current. Placement is never evidence and never affects rank.
[](https://sourcey.com/log/github/agent-readiness/github-rest-api/repository-operations)Improve the report
Correct it, rerun it, or improve the funnel.
- Profile
- arp_01kzf0m4x9v5n7pd3j2gc8q1fk
- Projection
- sha256:3a41317759a471cf0c46745bf258d1a9dfc082027c87f195c14746ac2523392b
- Policy
- service-use-2026-09-07-blocking-barriers-r12 · sha256:fc9e8f046d86fcf19ab2f1bc547219e503cdc11ffa135d020db7285965cd7d1d
Every request carries these exact identifiers.How report cards are assessed →View the exact declaration