canonical: https://jentic.com/apis/github.com/github-ghec # GitHub v3 REST API (GHEC) The GitHub v3 REST API for GitHub Enterprise Cloud (GHEC) exposes the full developer-platform surface - repositories, issues, pull requests, Actions workflows, code scanning, Dependabot, billing, and enterprise-level admin operations. Agents can manage source control, drive CI/CD, audit security alerts, and administer organisations and enterprise accounts. Authentication is a Bearer token (personal access token, GitHub App installation token, or fine-grained token) and the spec covers more than 1,000 endpoints across 70+ tag groups. ## For AI agents Manage repositories, issues, pull requests, Actions runs, security alerts, and enterprise admin tasks across GitHub Enterprise Cloud organisations. ## Scope Does not handle GitHub Server (self-hosted appliance) admin endpoints, the GraphQL v4 API, or chat-style Copilot APIs - use for GitHub Enterprise Cloud REST operations only. ## Capabilities - Open, comment on, and close issues and pull requests across repositories - Trigger and inspect GitHub Actions workflow runs and read job logs - List and resolve code-scanning, secret-scanning, and Dependabot alerts - Administer organisations, teams, and seats across a GHEC enterprise - Pull audit logs and SAML SSO state for compliance reporting - Manage repository contents - create commits, branches, releases, and tags - Read billing and usage data for Actions, Packages, and shared storage ## Use cases ### Pull Request Automation Automate pull request workflows - opening, requesting reviewers, applying labels, and merging when checks pass. POST /repos/{owner}/{repo}/pulls creates the PR; POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers adds reviewers; PUT /repos/{owner}/{repo}/pulls/{pull_number}/merge completes the merge once required checks succeed. Example prompt: Open a pull request from feature/x into main with title 'Refactor auth' and request review from team @platform ### Security Alert Triage Triage code-scanning, secret-scanning, and Dependabot alerts across an enterprise. List alerts via GET /enterprises/{enterprise}/code-scanning/alerts and GET /enterprises/{enterprise}/secret-scanning/alerts, then dismiss or resolve each via the per-alert PATCH endpoints with a reason and comment for audit. Example prompt: List all open code-scanning alerts at severity=high across the enterprise and return repository, rule_id, and html_url for each ### CI/CD Workflow Orchestration Drive GitHub Actions from outside the platform - dispatch a workflow on demand, poll its run status, and pull job logs for failure analysis. POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches starts a run; GET /repos/{owner}/{repo}/actions/runs/{run_id} reports its conclusion. Example prompt: Dispatch the workflow deploy.yml on branch main with input env=staging, then poll runs until conclusion is success or failure ### Enterprise Audit and Compliance Pull audit logs and SSO state for SOC 2 and ISO 27001 evidence. GET /enterprises/{enterprise}/audit-log paginates events across organisations, and GET /enterprises/{enterprise}/consumed-licenses produces the seat-level inventory that compliance reviewers expect, fully driven from API calls. Example prompt: Paginate the enterprise audit log over the last 24 hours and return action, actor, and created_at for every event of type repo.access ### AI Agent Code Operations Use Jentic to let an AI agent execute concrete code-platform actions. The agent issues an intent like 'open a pull request', Jentic resolves the matching GitHub operation, executes it with the Bearer token held in the vault, and returns the new PR URL the agent can post back to chat. Example prompt: Through Jentic, create a pull request from branch fix/typo into main with title 'Fix typo in README' and return the html_url ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | /repos/{owner}/{repo}/pulls | Create a pull request | | POST | /repos/{owner}/{repo}/issues | Open an issue | | POST | /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches | Dispatch a workflow run | | GET | /enterprises/{enterprise}/audit-log | Get the enterprise audit log | | GET | /repos/{owner}/{repo}/code-scanning/alerts | List code-scanning alerts | | GET | /repos/{owner}/{repo}/dependabot/alerts | List Dependabot alerts | | PUT | /repos/{owner}/{repo}/pulls/{pull_number}/merge | Merge a pull request | | GET | /search/code | Search code across repositories | ## Key resources - **Repos** — Repository CRUD, contents, branches, and commits - **Issues** — Issues, comments, labels, and assignments - **Pulls** — Pull requests, reviews, and merges - **Actions** — Workflows, runs, jobs, runners, and secrets - **Code Scanning** — CodeQL alerts and analyses - **Secret Scanning** — Detected secrets across repositories - **Dependabot** — Vulnerability alerts and automated updates - **Orgs** — Organisation membership, teams, and roles - **Enterprise Admin** — Enterprise-level administration and audit - **Billing** — Usage and billing for Actions, Packages, and storage - **Search** — Search code, issues, repositories, users, and commits ## Why Jentic - **Setup:** Wiring the GitHub Enterprise Cloud REST API by hand means attaching a bearer token, whether a PAT, fine-grained token, or App installation token, to every request to api.github.com and rotating those tokens across callers yourself. Through Jentic you install once, import the GitHub v3 REST API from the API Directory, store the token once, and your agent calls it. - **Permission scoping:** GitHub puts the owner and repo in the URL path (/repos/{owner}/{repo}/...), so a rule can pin your agent to one repository: it can open pull requests and issues there and nothing else. You choose the operations it may call, so destructive ones like merging a pull request or dispatching a workflow are not included unless you add them. - **Credential handling:** Your GitHub token is stored once, encrypted, by your own Jentic One instance and injected at execution time, and can be rotated centrally. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'create a pull request' or 'list code-scanning alerts', and Jentic returns the matching GitHub operation with its input schema so the agent picks the right one of over a thousand endpoints without browsing the reference docs. ## Related APIs - **GitLab API** — All-in-one DevOps platform with similar repo, MR, and CI surface - **Jira API** — Issue tracking system commonly synced bidirectionally with GitHub issues and PRs - **Slack Web API** — Notify channels when GHEC events fire - PR opened, alert triggered, deploy run ## FAQ ### What authentication does the GitHub GHEC API use? GHEC accepts Bearer tokens - personal access tokens, fine-grained tokens, or GitHub App installation tokens - passed as Authorization: Bearer . Through Jentic the token is held in your encrypted Jentic One instance, so the agent gets a scoped execution token and the raw secret never enters the prompt context. ### Can I open a pull request with the GitHub GHEC API? Yes. POST /repos/{owner}/{repo}/pulls creates a pull request from head into base with a title and body, then POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers adds reviewers and PUT /repos/{owner}/{repo}/pulls/{pull_number}/merge completes the merge once checks pass. ### What are the rate limits for the GitHub GHEC API? Authenticated REST requests are capped at 5,000 per hour per user, 15,000 per hour for GitHub Apps installed on enterprise organisations, and the search endpoints have a separate 30-per-minute cap. Exceeding the cap returns HTTP 403 with X-RateLimit-Reset; back off until the window resets. ### How do I trigger a GitHub Actions workflow through Jentic? Search Jentic for 'trigger a github actions workflow', load POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches, and execute with ref set to the branch and inputs to the workflow input map. Poll GET /repos/{owner}/{repo}/actions/runs to read the resulting run conclusion. ### Does the GHEC API expose enterprise-level audit and billing? Yes. GET /enterprises/{enterprise}/audit-log paginates every audit event across the enterprise's organisations, and the /enterprises/{enterprise}/settings/billing/* endpoints expose Actions, Packages, and storage usage. Both require a token granted enterprise admin scope. ### Can I read code-scanning and Dependabot alerts via the API? Yes. GET /repos/{owner}/{repo}/code-scanning/alerts lists CodeQL findings and GET /repos/{owner}/{repo}/dependabot/alerts lists vulnerable-dependency findings. Filter by state=open and severity=high to drive a triage queue, and PATCH the per-alert endpoint to dismiss with a documented reason. ### How is the GHEC API different from github.com REST API? GHEC ships extra endpoints under /enterprises/{enterprise} for SAML SSO, consumed licences, and enterprise audit log streaming, plus stricter authentication options like SAML-bound tokens. The core resource endpoints (repos, issues, pulls, actions) are identical and share the api.github.com host. ### Can I limit what my agent is allowed to do with the GitHub GHEC API? Yes. Because you run Jentic One self-hosted, your own rules decide which GitHub operations and credentials the agent may use, and GHEC puts the owner and repo in the URL path (/repos/{owner}/{repo}/...), so a rule can pin the agent to a single repository where it opens pull requests and issues and nothing else. You choose the exact operations it may call, so destructive ones like merging a pull request (PUT /repos/{owner}/{repo}/pulls/{pull_number}/merge) or dispatching a workflow (POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches) are excluded unless you add them. The stored token is injected only at execution time for the operations you allowed, so the agent cannot reach enterprise audit or billing endpoints it was never granted.