GitHub Search API for repositories, issues, and pull requests
Search GitHub over HTTP and receive repositories, issues, and pull requests in one result list, each labelled with `kind`, without handling GitHub tokens or rate limits yourself.
Endpoint
Results arrive in the same JSON shape as every other engine, with extra fields that tell repositories apart from threads.
`kind` is `repo`, `issue`, `pr`, or `discussion`, so a parser can branch without reading the URL.
A repo snippet looks like `Rust | 5113 stars | description`. `stars` and `language` are also separate fields.
An issue snippet starts `TanStack/router · issue · open · 2 comments`. Pull requests and discussions follow the same pattern.
Useful for
Coding agents / Incident lookup / Dependency research
Code and the threads around it, without a GitHub token
Set `search_service` to `github` and the results mix repositories with matching issues and pull requests. The endpoint, the authentication, and the shared result shape are the same as every other engine. A GitHub qualifier such as `is:issue` limits the search to one kind.
Mixed kinds on one page
A query like a hydration error returns the matching issues and discussions, not only repositories. Results are ordered by how many query terms they carry, then by stars, so a page is not all one kind when another kind also matched.
Qualifiers search one type
Append a GitHub qualifier such as `is:issue` or `stars:>1000` and only that type is searched. Without a qualifier, repositories, issues, and pull requests are included.
Creation-date time range
`time_range` limits repositories and threads to those *created* in the window. It previously filtered repositories by last push, which let years-old repos through a "this week" query.
No GitHub rate limit to manage
Requests are billed against Search1API credits rather than a GitHub token, so there is no per-token hourly ceiling to work around. Discussions additionally require the service GitHub token; without it, repositories, issues, and pull requests still return.
What is a GitHub search API?
A GitHub search API is an HTTP interface that returns GitHub repositories, issues, pull requests, and discussions as structured results. GitHub publishes its own search endpoint, but it requires a personal access token, applies a low per-token rate limit to search specifically, and returns a large payload that has to be reduced before it is useful to a model. Search1API exposes GitHub as one of the search services on its Search endpoint, labelling every result with `kind` and putting language, stars, or comment counts in the snippet, in the same JSON shape it returns for its other engines. That makes it practical for coding agents that need to find a library *or* the issue that describes a failure, inside a single tool call.
Typical workflow
Search GitHub over HTTP and receive repositories, issues, and pull requests in one result list, each labelled with `kind`, without handling GitHub tokens or rate limits yourself.
Send a query with `search_service` set to `github`.
Read `kind` first. For `repo`, split the snippet on the pipe for language and stars. For `issue` or `pr`, the snippet already names the repo, state, and comment count.
Append `is:issue` when you only want threads, or set `crawl_results` when the workflow needs README or issue-body text.
One request, code and the threads around it
A single call searches GitHub repositories, issues, and pull requests, and labels each result with kind, which is usually enough to pick a library or the matching issue without a follow-up request.
bash
Best for
Coding agents that need to find a library or the issue that describes a failure before they edit code.
Incident lookup that should return the GitHub thread, not only the repository.
Technology scouting that tracks which projects are gaining traction.
Documentation tools that resolve a package name to its source repository.
FAQ
How is this different from the GitHub search API?
GitHub’s own search endpoint requires a personal access token and applies a low rate limit to search requests specifically. Search1API bills against its own credits, so there is no GitHub token to provision or rotate, and it returns a compact result labelled with `kind` — language and stars on repositories, comment counts on threads — rather than a large JSON object to reduce.
Do I need a GitHub token?
No. Authentication is your Search1API key. The request is a POST to https://api.search1api.com/search with `search_service` set to `github`. Discussions additionally require the service GitHub token; without it, the other kinds still return.
Can I search only issues?
Yes. Append a GitHub qualifier such as `is:issue` or `is:pr` to search one type. Without a qualifier, repositories, issues, and pull requests are mixed. Discussions are included when the service GitHub token is configured; without it they are omitted and the other kinds still return.
Can I get the README of a repository?
Yes. Set `crawl_results` to the number of top results you want fetched, and each page retrieved successfully includes a `content` field with the page text as markdown. Results that cannot be retrieved are returned without `content` and are not charged.
What does a GitHub search cost?
One credit per search, and one additional credit for each page retrieved successfully through `crawl_results`. At the base top-up rate of $1 for 1,000 credits, that is $1 per 1,000 searches. Signup includes 100 free credits with no credit card.
Which other developer sources are supported?
The same Search endpoint accepts `arxiv` for papers, `reddit` for community discussion, and `x` for posts, alongside general web engines and the Chinese-language engines, for 19 engines in total on one contract.
Can I use it with Python, JavaScript, or cURL?
Yes. Search1API is a REST API that works with any HTTP client, and GitHub is a parameter value rather than a separate integration. The official TypeScript and Python SDKs, the CLI, and the MCP server all accept the same `search_service` value.