REST API endpoints for search

Use the REST API to search for specific items on GitHub.

You can use the REST API to search for the specific item you want to find. For example, you can find a user or a specific file in a repository. Think of it the way you think of performing a search on Google. It's designed to help you find the one result you're looking for (or maybe the few results you're looking for). Just like searching on Google, you sometimes want to see a few pages of search results so that you can find the item that best meets your needs. To satisfy that need, the GitHub REST API provides up to 1,000 results for each search.

You can narrow your search using queries. To learn more about the search query syntax, see REST API endpoints for search.

Ranking search results

Unless another sort option is provided as a query parameter, results are sorted by best match in descending order. Multiple factors are combined to boost the most relevant item to the top of the result list.

Rate limit

The REST API has a custom rate limit for searching. For authenticated requests, you can make up to
30 requests per minute for all search endpoints except for the Search code endpoint. The Search code endpoint requires you to authenticate and limits you to 10 requests per minute. For unauthenticated requests, the rate limit allows you to make up to 10 requests per minute.

For information about how to determine your current rate limit status, see Rate Limit.

Constructing a search query

Each endpoint for searching uses query parameters to perform searches on GitHub. See the individual endpoints for examples that include the endpoint and query parameters.

A query can contain any combination of search qualifiers supported on GitHub. The format of the search query is:

SEARCH_KEYWORD_1 SEARCH_KEYWORD_N QUALIFIER_1 QUALIFIER_N

For example, if you wanted to search for all repositories owned by defunkt that
contained the word GitHub and Octocat in the README file, you would use the
following query with the search repositories endpoint:

GitHub Octocat in:readme user:defunkt

Note: Be sure to use your language's preferred HTML-encoder to construct your query strings. For example:

// JavaScript
const queryString = 'q=' + encodeURIComponent('GitHub Octocat in:readme user:defunkt');

See Searching on GitHub
for a complete list of available qualifiers, their format, and an example of
how to use them. For information about how to use operators to match specific
quantities, dates, or to exclude results, see Understanding the search syntax.

Limitations on query length

You cannot use queries that:

These search queries will return a "Validation failed" error message.

Search scope limits

To keep the REST API fast for everyone, we limit the number of repositories a query will search through. The REST API will find up to 4,000 repositories that match your filters and return results from those repositories.

Timeouts and incomplete results

To keep the REST API fast for everyone, we limit how long any individual query
can run. For queries that exceed the time limit,
the API returns the matches that were already found prior to the timeout, and
the response has the incomplete_results property set to true.

Reaching a timeout does not necessarily mean that search results are incomplete.
More results might have been found, but also might not.

Access errors or missing search results

You need to successfully authenticate and have access to the repositories in your search queries, otherwise, you'll see a 422 Unprocessable Entry error with a "Validation Failed" message. For example, your search will fail if your query includes repo:, user:, or org: qualifiers that request resources that you don't have access to when you sign in on GitHub.

When your search query requests multiple resources, the response will only contain the resources that you have access to and will not provide an error message listing the resources that were not returned.

For example, if your search query searches for the octocat/test and codertocat/test repositories, but you only have access to octocat/test, your response will show search results for octocat/test and nothing for codertocat/test. This behavior mimics how search works on GitHub.

Text match metadata

On GitHub, you can use the context provided by code snippets and highlights in search results. The endpoints for searching return additional metadata that allows you to highlight the matching search terms when displaying search results.

Requests can opt to receive those text fragments in the response, and every fragment is accompanied by numeric offsets identifying the exact location of each matching search term.

To get this metadata in your search results, specify the text-match media type in your Accept header.

application/vnd.github.text-match+json

When you provide the text-match media type, you will receive an extra key in the JSON payload called text_matches that provides information about the position of your search terms within the text and the property that includes the search term. Inside the text_matches array, each object includes
the following attributes:

Name Description
object_url The URL for the resource that contains a string property matching one of the search terms.
object_type The name for the type of resource that exists at the given object_url.
property The name of a property of the resource that exists at object_url. That property is a string that matches one of the search terms. (In the JSON returned from object_url, the full content for the fragment will be found in the property with this name.)
fragment A subset of the value of property. This is the text fragment that matches one or more of the search terms.
matches An array of one or more search terms that are present in fragment. The indices (i.e., "offsets") are relative to the fragment. (They are not relative to the full content of property.)

Example

Using a curl command, and the example issue search above, our API
request would look like this:

curl -H 'Accept: application/vnd.github.text-match+json' \
'https://api.github.com/search/issues?q=windows+label:bug \
+language:python+state:open&sort=created&order=asc'

The response will include a text_matches array for each search result. In the JSON below, we have two objects in the text_matches array.

The first text match occurred in the body property of the issue. We see a fragment of text from the issue body. The search term (windows) appears twice within that fragment, and we have the indices for each occurrence.

The second text match occurred in the body property of one of the issue's comments. We have the URL for the issue comment. And of course, we see a fragment of text from the comment body. The search term (windows) appears once within that fragment.

{
  "text_matches": [
    {
      "object_url": "https://api.github.com/repositories/215335/issues/132",
      "object_type": "Issue",
      "property": "body",
      "fragment": "comprehensive windows font I know of).\n\nIf we can find a commonly
      distributed windows font that supports them then no problem (we can use html
      font tags) but otherwise the '(21)' style is probably better.\n",
      "matches": [
        {
          "text": "windows",
          "indices": [
            14,
            21
          ]
        },
        {
          "text": "windows",
          "indices": [
            78,
            85
          ]
        }
      ]
    },
    {
      "object_url": "https://api.github.com/repositories/215335/issues/comments/25688",
      "object_type": "IssueComment",
      "property": "body",
      "fragment": " right after that are a bit broken IMHO :). I suppose we could
      have some hack that maxes out at whatever the font does...\n\nI'll check
      what the state of play is on Windows.\n",
      "matches": [
        {
          "text": "Windows",
          "indices": [
            163,
            170
          ]
        }
      ]
    }
  ]
}

Note

Most endpoints use Authorization: Bearer <YOUR-TOKEN> and Accept: application/vnd.github+json headers, plus X-GitHub-Api-Version: 2026-03-10. Curl examples below omit these standard headers for brevity.

Search code

GET /search/code

Searches for query terms inside of a file. This method returns up to 100 results per page.
When searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Considerations for code search:
Due to the complexity of searching code, there are a few restrictions on how searches are performed:

Only the default branch is considered. In most cases, this will be the master branch.
Only files smaller than 384 KB are searchable.
You must always include at least one search term when searching source code. For example, searching for language:go is not valid, while amazing language:go is.

This endpoint requires you to authenticate and limits you to 10 requests per minute.

Parameters

Headers

Path and query parameters

HTTP response status codes

Code examples

Example

Request:

curl -L \
  -X GET \
  "https://api.github.com/search/code?q=Q"

Response schema (Status: 200):

Search commits

GET /search/commits

Find commits via various criteria on the default branch (usually main). This method returns up to 100 results per page.
When searching for commits, you can get text match metadata for the message field when you provide the text-match media type. For more details about how to receive highlighted search results, see Text match
metadata.
For example, if you want to find commits related to CSS in the octocat/Spoon-Knife repository. Your query would look something like this:
q=repo:octocat/Spoon-Knife+css

Parameters

Headers

Path and query parameters

HTTP response status codes

Code examples

Example

Request:

curl -L \
  -X GET \
  "https://api.github.com/search/commits?q=Q"

Response schema (Status: 200):

Search issues and pull requests

GET /search/issues

Find issues by state and keyword. This method returns up to 100 results per page.
When searching for issues, you can get text match metadata for the issue title, issue body, and issue comment body fields when you pass the text-match media type. For more details about how to receive highlighted
search results, see Text match metadata.
For example, if you want to find the oldest unresolved Python bugs on Windows. Your query might look something like this.
q=windows+label:bug+language:python+state:open&sort=created&order=asc
This query searches for the keyword windows, within any open issue that is labeled as bug. The search runs across repositories whose primary language is Python. The results are sorted by creation date in ascending order, which means the oldest issues appear first in the search results.
Note

For requests made by GitHub Apps with a user access token, you can't retrieve a combination of issues and pull requests in a single query. Requests that don't include the is:issue or is:pull-request qualifier will receive an HTTP 422 Unprocessable Entity response. To get results for both issues and pull requests, you must send separate queries for issues and pull requests. For more information about the is qualifier, see "Searching only issues or pull requests."

Parameters

Headers

Path and query parameters

HTTP response status codes

Code examples

Example 1: Status Code 200

Request:

curl -L \
  -X GET \
  "https://api.github.com/search/issues?q=Q"

Response schema (Status: 200):

Example 2: Status Code 200

Request:

curl -L \
  -X GET \
  "https://api.github.com/search/issues?q=Q"

Response schema (Status: 200):

Search labels

GET /search/labels

Find labels in a repository with names or descriptions that match search keywords. Returns up to 100 results per page.
When searching for labels, you can get text match metadata for the label name and description fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find labels in the linguist repository that match bug, defect, or enhancement. Your query might look like this:
q=bug+defect+enhancement&repository_id=64778136
The labels that best match the query appear first in the search results.

Parameters

Headers

Path and query parameters

HTTP response status codes

Code examples

Example

Request:

curl -L \
  -X GET \
  "https://api.github.com/search/labels?repository_id=REPOSITORY_ID&q=Q"

Response schema (Status: 200):

Search repositories

GET /search/repositories

Find repositories via various criteria. This method returns up to 100 results per page.
When searching for repositories, you can get text match metadata for the name and description fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to search for popular Tetris repositories written in assembly code, your query might look like this:
q=tetris+language:assembly&sort=stars&order=desc
This query searches for repositories with the word tetris in the name, the description, or the README. The results are limited to repositories where the primary language is assembly. The results are sorted by stars in descending order, so that the most popular repositories appear first in the search results.

Parameters

Headers

Path and query parameters

HTTP response status codes

Code examples

Example

Request:

curl -L \
  -X GET \
  "https://api.github.com/search/repositories?q=Q"

Response schema (Status: 200):

Search topics

GET /search/topics

Find topics via various criteria. Results are sorted by best match. This method returns up to 100 results per page. See "Searching topics" for a detailed list of qualifiers.
When searching for topics, you can get text match metadata for the topic's short_description, description, name, or display_name field when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to search for topics related to Ruby that are featured on https://github.com/topics. Your query might look like this:
q=ruby+is:featured
This query searches for topics with the keyword ruby and limits the results to find only topics that are featured. The topics that are the best match for the query appear first in the search results.

Parameters

Headers

Path and query parameters

HTTP response status codes

Code examples

Example

Request:

curl -L \
  -X GET \
  "https://api.github.com/search/topics?q=Q"

Response schema (Status: 200):

Search users

GET /search/users

Find users via various criteria. This method returns up to 100 results per page.
When searching for users, you can get text match metadata for the issue login, public email, and name fields when you pass the text-match media type. For more details about highlighting search results, see Text match metadata. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you're looking for a list of popular users, you might try this query:
q=tom+repos:%3E42+followers:%3E1000
This query searches for users with the name tom. The results are restricted to users with more than 42 repositories and over 1,000 followers.
This endpoint does not accept authentication and will only include publicly visible users. As an alternative, you can use the GraphQL API. The GraphQL API requires authentication and will return private users, including Enterprise Managed Users (EMUs), that you are authorized to view. For more information, see "GraphQL Queries."

Parameters

Headers

Path and query parameters

HTTP response status codes

Code examples

Example

Request:

curl -L \
  -X GET \
  "https://api.github.com/search/users?q=Q"

Response schema (Status: 200):