canonical: https://jentic.com/apis/github.com/github-rest

# GitHub v3 REST API

The GitHub v3 REST API is the programmatic surface for GitHub. It covers repositories and their contents, commits, branches, and releases; collaboration through issues, pull requests, reviews, and comments; and automation through Actions workflows, runs, and artifacts. Beyond code it reaches users and organizations, teams and memberships, gists, checks, deployments, webhooks, and repository and code search. Because it spans read and write across the whole platform, a single token can both fetch data and change it, so scoping what an agent may call is central to using it safely.

## For AI agents

Work with GitHub programmatically: repositories, contents, commits, issues, pull requests, Actions, users and organizations, webhooks, and search across the platform.

## Scope

Covers the GitHub v3 REST API surface for repositories, collaboration, Actions, and administration. It does not cover the GitHub GraphQL API or GitHub Enterprise Server, which have their own specs.

## Capabilities

- Read and manage repositories, their contents, commits, and branches
- Open, list, and comment on issues and pull requests
- Search repositories, code, issues, and users
- Trigger and inspect GitHub Actions workflows, runs, and artifacts
- Manage organizations, teams, and their memberships
- Create and manage releases, deployments, and webhooks
- Read and update authenticated-user resources such as repos and gists

## Use cases

### AI Agent That Triages Issues and PRs

A development agent reads open issues and pull requests, comments with a summary or suggested labels, and links related work. Through Jentic it lists issues, reads pull request details, and posts comments using scoped permissions, so it can help maintainers without holding a broad token. The agent discovers the issue and pull request operations by intent rather than being wired to specific routes by hand.

Example prompt: List open issues for a repository, summarize each, and post a comment suggesting labels, calling only the read and comment operations you allow

### Repository and Code Automation

A platform tool provisions and maintains repositories from code: creating repos, reading and updating file contents, and cutting releases. It uses the contents and repository endpoints to keep files and metadata in sync, and can gate write operations behind approval so automation stays controlled.

Example prompt: Create a repository for the authenticated user, commit an initial README through the contents endpoint, and tag a first release

### CI/CD Orchestration with Actions

A pipeline tool drives GitHub Actions: triggering workflows, watching runs, and collecting artifacts and logs. It reads run status to gate deployments and reports results back to a dashboard. Routing this through the API lets teams orchestrate builds and deployments beyond what the default triggers cover.

Example prompt: Trigger a workflow, poll its run status until it completes, and fetch the produced artifacts for the release step

### Codebase Search and Discovery

A knowledge or coding assistant answers questions about where things live across many repos. It uses repository and code search to find matching files and repos, then reads the relevant contents to ground its answer. Search plus read-only access lets the assistant explore without any write permissions.

Example prompt: Search repositories for a query, pick the top matches, and read the relevant file contents to answer where a function is defined

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/repos/{owner}/{repo}` | Get a repository's details |
| GET | `/repos/{owner}/{repo}/issues` | List issues for a repository |
| POST | `/repos/{owner}/{repo}/issues` | Open an issue on a repository |
| GET | `/repos/{owner}/{repo}/pulls` | List pull requests for a repository |
| GET | `/repos/{owner}/{repo}/contents/{path}` | Read a file's contents |
| GET | `/search/repositories` | Search repositories by query |
| POST | `/user/repos` | Create a repository for the authenticated user |

## Key resources

- **Repositories** — Repos, contents, commits, branches, and releases
- **Issues and pull requests** — Issues, pull requests, reviews, and comments for collaboration
- **Actions** — Workflows, runs, jobs, and artifacts for CI/CD automation
- **Users and organizations** — Users, organizations, teams, and memberships
- **Search** — Search across repositories, code, issues, and users
- **Webhooks and deployments** — Webhooks, checks, and deployment resources

## Why Jentic

- **Setup:** The GitHub REST API is vast and every call needs a bearer token, so wiring it by hand means managing that token, paginating large collections, and mapping intents onto more than a thousand operations. Through Jentic you install once, import the API from the Directory, and your agent finds and calls the right operation.
- **Permission scoping:** One GitHub token can read and write across the whole platform, so scoping is the safeguard. You allow only the operations a task needs, keeping destructive ones like deleting a repository or force-updating contents out of the allowed set. Rules run on your own instance and every call the agent makes is logged.
- **Credential handling:** Your GitHub personal access token is stored once, encrypted, by your own Jentic One instance and injected into the Authorization header at execution time, so it never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'open a GitHub issue' or 'search repositories', and Jentic returns the matching operation with its input schema, which matters most on an API this large where browsing docs for the right route is slow.

## Related APIs

- **GitLab API** — Source control, issues, and CI/CD on the GitLab platform
- **Bitbucket API** — Git repository hosting with pull requests and pipelines
- **CircleCI API** — Continuous integration pipelines triggered from your repositories

## FAQ

### What authentication does the GitHub REST API use?

Per this OpenAPI spec it uses HTTP bearer authentication: you send a GitHub personal access token in the Authorization header as a bearer token. Through Jentic that token is stored encrypted on your own instance and injected at call time, so it never appears in the agent's prompt or logs.

### How do I open an issue on a repository with the GitHub REST API?

Call POST `/repos/{owner}/{repo}/issues` with a title and body, and use GET `/repos/{owner}/{repo}/issues` to list existing issues. Through Jentic you search for the intent 'open a GitHub issue' and the agent gets the operation and its input schema, then supplies the owner and repo.

### Can the GitHub REST API run and inspect GitHub Actions?

Yes. The API covers Actions workflows, runs, jobs, and artifacts, so an agent can trigger a workflow, poll a run until it finishes, and download the artifacts it produced. This lets you orchestrate CI/CD beyond the default event triggers.

### What are the rate limits for the GitHub REST API?

The OpenAPI spec does not encode the exact numeric limits; GitHub enforces per-token limits that vary by authentication and endpoint, and responses carry remaining-quota headers. Read those headers and back off when they run low, and check https://docs.github.com for current limits.

### How do I search code and repositories with the GitHub REST API?

Use GET `/search/repositories` to find repositories by query, and the API also exposes code, issue, and user search. An agent can search for matches, then read file contents to ground an answer, all without any write permissions.

### Can I limit what my agent is allowed to do with the GitHub REST API?

Yes, and it matters because one token can both read and write across GitHub. You allow only the operations a task needs, such as GET `/repos/{owner}/{repo}` and GET `/search/repositories`, and keep destructive ones like deleting a repository out of the allowed set. Through Jentic these rules run on your own instance and every call is logged.

### Is there a GitHub MCP server?

You don't need a separate MCP server to give your agent the GitHub REST API. Jentic connects it directly from the API Directory: import the API, scope the operations, and your agent works with repos, issues, and Actions without loading another server's tool definitions into its context.
