# ExplainGitHub API

## ExplainGitHub API lets you build repo-aware AI features

Use repository context to power codebase chat, developer copilots, support tools, and internal workflows.

### Instantly Understand Any GitHub Repository

Save hours of code review time with our official browser extension.

[Add to Browser](https://microsoftedge.microsoft.com/addons/detail/explaingithub-%E2%80%93-turn-hour/mopfjhaboemmacmpeckofbiaokhpbike)

ExplainGitHub API is now live. Read the launch and technical walkthrough.

[Read more](/content/blog/ExplainGitHub-API/index.html)

# How ExplainGitHub API Works

How ExplainGitHub API works is simple at a high level: you connect repositories, generate an API key, and send repo-aware requests into endpoints that understand codebase context instead of treating the repository like raw text pasted into a prompt.

This post is the technical companion to the launch announcement. If you want the full endpoint reference, request shapes, and integration details, start with the [developer docs](https://explaingithub-developer-docs.shivam-maurya.workers.dev/).

## The core idea

Most AI integrations fail in technical teams for one reason: the model does not have the right context at the right time.

ExplainGitHub API solves that by making repository context a first-class part of the request flow.

Instead of building your own stack for:

- repository connection
- repository registration
- repo identity management
- usage tracking
- credit management
- private-repo access flows

you use the API dashboard and API layer that already handle those pieces.

## The basic flow

At a practical level, the workflow looks like this:

1. Create or select an organization in the API dashboard
2. Generate an API key
3. Connect repositories
4. Use repo-aware endpoints from your product or internal system
5. Track usage, credits, and request history from the dashboard

That sounds simple, but it matters because it gives teams a stable operating model instead of a collection of one-off scripts.

## How repositories are connected

There are two useful ways to think about repository connection.

### Public or direct repo registration

If you already know the repository URL you want to work with, you can register it and get a stable `repo_id`.

That `repo_id` becomes the reference you use in your app when calling query and chat-style endpoints.

This is useful when your product or workflow already knows which repository it should target.

### GitHub App connection for private repositories

For private-repo workflows, the model is cleaner:

- connect the GitHub App
- let the backend handle installation linking
- use the repositories returned for that installation
- use the returned `repo_id` values directly when the repo is already registered

This matters because teams do not have to ask users for PATs or build their own private-repo auth flow.

## How the API is used in practice

The easiest way to understand the API is to think in terms of surfaces where repository context can help.

### Inside products

A developer-facing product can add:

- ask-this-repo chat
- issue copilots
- PR summaries
- codebase Q&A

This is useful for tools that want to feel context-aware without building their own repository-understanding layer.

### Inside internal systems

An engineering organization can build:

- internal copilots for onboarding
- debugging assistants
- release investigation tools
- support-facing repo lookup tools

This reduces the need to route every question through the same senior engineers.

### Inside workflows and automation

Teams can use the API in:

- CI helpers
- docs assistants
- internal support tooling
- workflow diagnostics

This is where the API becomes operationally efficient. It is not just answering questions. It is shortening the path from question to action.

## Why this is efficient for teams

The real efficiency gain is not “one more AI feature.”

It is that teams can reuse a single repository-aware layer across multiple use cases:

- one dashboard for keys, repos, usage, and credits
- one API model for product features and internal tools
- one repo identity layer using stable `repo_id` values
- one private-repo connection model through GitHub App

That lowers the amount of platform work needed before a team can ship something useful.

Instead of building a custom repo-ingestion and auth setup for every experiment, teams can start with an existing foundation and focus on the actual user experience.

## What to build first

If you are evaluating the API, start with a single workflow that already creates friction in your team.

Good first projects:

- an internal “ask our repo” tool for engineering
- a support assistant that answers product questions using connected repos
- a PR or issue summary tool inside your own app
- a release or CI helper that uses repository context during investigation

These are good starting points because they are easy to test, easy to measure, and close to day-to-day team pain.

## Where to go deeper

This post is the conceptual technical view.

For endpoint references, auth details, request examples, and integration specifics, use the [developer docs](https://explaingithub-developer-docs.shivam-maurya.workers.dev/).

If you want the product story and launch context, read the announcement post as well.