tag is parsed. Two tags cover both CORS-tagged and non-CORS fetches. -->Build a GitHub API integration for AI agents using Nango | Nango Blog<br>Theme

Table of Contents

This guide shows how to build a custom, customer-facing GitHub API integration that the AI agents in your product can act on, using Nango and an AI coding agent (Codex, Claude Code, Cursor, or any other).<br>By the end of this guide, you will have:<br>The ability for an AI agent in your product to create issues, comment on pull requests, and open PRs on a customer’s repositories, exposed as typed MCP tool calls instead of raw GitHub API parameters.<br>A GitHub auth UI in your product (Nango Connect) so your customers can connect their own GitHub account or install your GitHub App.<br>A durable sync that imports issues and pull requests from a customer’s repositories and keeps them up to date, so the agent always reasons over current data.<br>A signature-verified webhook handler that reacts to GitHub events (pushes, pull requests, issues) in real time.<br>Get the working example: the complete demo (frontend, backend, nango-integrations) is on GitHub at NangoHQ/github-api-integration. Clone it to run the whole thing end to end, or follow the guide below and let Codex generate the same functions in your own project.<br>What is a GitHub API integration?<br>A GitHub API integration connects your application or agent to a customer’s GitHub data (repositories, issues, pull requests, and commits) through GitHub’s REST and GraphQL APIs. It authenticates as a GitHub App or an OAuth App, reads data into your app with scheduled syncs, writes back with actions like creating issues or commenting on pull requests, and reacts to repository events through webhooks.<br>Example use cases: an AI agent that triages a customer’s issues and opens pull requests, an AI code-review product that comments on PRs, a project management tool that mirrors a customer’s issues, or a developer analytics dashboard.<br>Why is it hard to integrate the GitHub API into your app?<br>The GitHub REST API exposes repositories, issues, pull requests, commits, and webhooks. A production integration on top of it takes a few decisions up front, plus the infrastructure to keep them running.<br>The first is the auth type. For a customer-facing product, a GitHub App is usually the right call; reach for an OAuth App only when you are building a personal-developer tool that should act purely as the user.<br>CapabilityGitHub AppOAuth AppActs asA bot/installationThe authorizing userFine-grained permissionsYes, per resourceNo, inherits the user's scopeRate limit5,000 to 12,500/hour (scales with org)5,000/hourRepository accessOnly repos granted at installEvery repo the user can accessBest forCustomer-facing productsPersonal-developer tools<br>See GitHub App vs. GitHub OAuth and GitHub’s own comparison for the full breakdown. The rest of the work is infrastructure:<br>The auth flow is not standard OAuth, and tokens are short-lived: GitHub App installation tokens expire after one hour. When “Expire user authorization tokens” is enabled (the default), user access tokens expire after 8 hours and refresh tokens after 6 months. A failed refresh shows up as the BAD_REFRESH_TOKEN error, usually after a rotated client secret or a revoked installation. Someone has to store, refresh, and encrypt all of this.<br>The Issues API also returns pull requests: GET /repos/{owner}/{repo}/issues returns both issues and PRs, and every pull request carries a pull_request field. Filter on it or you double-count.<br>Webhooks need signature verification: GitHub signs each delivery with the X-Hub-Signature-256 header (an HMAC-SHA256 of the raw body using your webhook secret). You verify it with a constant-time comparison before trusting the payload, and read the event type from X-GitHub-Event.<br>Pagination is header-driven: REST responses page through the Link header (rel="next", up to 100 items per page), and some data is only practical through GitHub’s GraphQL API, which has its own point budget.<br>Building all of this by hand takes weeks. With Nango and a coding agent like Codex, the same GitHub API integration ships in about an hour, the same workflow we used to build 200+ integrations across five APIs in 15 minutes.<br>Why use Nango for a GitHub API integration<br>Nango is the integration platform where coding agents build API integrations. An agent like Codex writes the integration as code in your repo, and Nango’s runtime runs it with managed auth, retries, and observability across 800+ APIs.<br>For a GitHub integration, we will use these Nango features:<br>Managed auth for GitHub Apps and OAuth: your product gets a customizable, white-label auth UI where customers install your GitHub App or authorize a GitHub OAuth app, while Nango handles installation and user tokens, refresh, encryption, and revocation behind it.<br>A function builder skill for Codex: to build your integration logic, Codex uses the Nango function builder skill. It researches the GitHub API, writes your actions and...