# GitHub Search API (https://www.socialcrawl.dev/platforms/github/search)

> Searches issues and PRs across all of GitHub via the `/search/issues` endpoint. Supports GitHub's full search syntax: qualifiers like `repo:owner/name`, `is:issue`, `is:pr`, `is:open`, `label:bug`, `created:>2026-01-01`, `author:username`, `comments:>10`. Sort by `reactions`, `comments`, `created`, or `updated`. Results land under `data.items[]` with `total_count` and `incomplete_results` siblings. Rate-limited to 30 req/min per token.

TL;DR: `GET /v1/github/search` costs 1 credit per call and returns SocialCrawl's unified JSON schema. Single x-api-key auth, 100 free credits on signup.

## Parameters

| Parameter | Required | Description |
| --- | --- | --- |
| `query` | yes | GitHub search query (uses GitHub's qualifier syntax: see https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests). |
| `sort` | no | Sort field: `reactions`, `comments`, `created`, `updated`. Defaults to best-match relevance. (reactions \| comments \| created \| updated) |
| `order` | no | `asc` or `desc`. Defaults to `desc`. (asc \| desc) |
| `per_page` | no | Results per page (1-100). Defaults to 30. |
| `page` | no | 1-indexed page number. |
| `since` | no | Only rows published on or after this date: YYYY-MM-DD (midnight UTC) or an ISO 8601 timestamp. Rows older than it are left off each page. This list is not in date order, so the walk does not stop at the date: keep following `next_cursor`, and each page costs what a page costs even when every row on it is filtered out. A row with no date is kept. `published_after`, `start_date`, `from_date`, `publish_time` (`yesterday`, `this-week`, `this-month`, `last-3-months`, `last-6-months`) and `max_age_days` are accepted and applied as `since`. |
| `until` | no | Only rows published on or before this date: YYYY-MM-DD (that whole UTC day is included) or an ISO 8601 timestamp. Newer rows are left off each page and the walk does not stop, so older pages follow. A row with no date is kept. `published_before`, `end_date` and `to_date` are accepted and applied as `until`. |
| `max_pages` | no | 1 to 50 (default 1, or 50 when `max_items` or `max_credits` is sent). Walk up to this many pages in one call and return the rows from all of them. Each page walked is billed exactly as one call to this endpoint (a cached page is free) and counts against your rate limit; its charge and any refund are recorded under the page's own request id, listed in `data.walk.request_ids`. The walk stops early at the last page, or when the request's time budget runs low; `data.walk.stopped` says why (`end`, `max_pages`, `max_items`, `max_credits`, `time_budget`, `page_error`) and `pagination.next_cursor` continues from where it stopped. |
| `max_items` | no | 1 to 5000. Get more in one call: keep walking pages until the response holds at least this many rows, then stop with `data.walk.stopped: "max_items"`. The last page is returned whole (it was billed), so `data.items` can hold up to one page more than this, and `pagination.next_cursor` resumes right after it without skipping a row. Walks up to 50 pages unless `max_pages` says fewer; each page is billed as one call (a cached page is free). Add `max_credits` to cap the spend. A long walk can stop on the time budget first (`"time_budget"`): send the returned cursor with the same params to continue. |
| `max_credits` | no | 1 to 100000. The most this call may spend, across every page it walks. A page starts only while the credits already spent plus that page's price (or, when higher, the most any page of this walk has cost) still fit, so the call never goes past it; the walk then stops with `data.walk.stopped: "max_credits"` and the cursor to resume. Sent alone, it walks as far as the budget goes (up to 50 pages). A value below the price of one page is a free 400 whose `error.details.page_credits` names that price. Credits a row join (`include=`) adds are known only once a page has run, so page 1 is checked against its own price. |

## Code example

```bash
curl -G "https://www.socialcrawl.dev/v1/github/search" \
  --data-urlencode "query=repo:vercel/next.js is:issue is:open" \
  -H "x-api-key: sc_YOUR_API_KEY"
```

## FAQ

### How do I search GitHub issues with an API?

Send a GET request to /v1/github/search with your search string in the query parameter. SocialCrawl searches GitHub issues and pull requests and returns matching items with title, repository, author, state, and comment count.

### Can I use GitHub search qualifiers in the query?

Yes. The query parameter accepts GitHub's search qualifiers, for example repo:owner/name, label:bug, state:open, author:handle, and is:pr. Combine them in one string exactly as you would in GitHub's own search bar.

### Does it search issues, pull requests, or both?

Both, since GitHub indexes issues and pull requests together. Narrow to one type with the is:issue or is:pr qualifier in your query. Each result carries a flag indicating which type it is so you can filter client-side too.

### How do I paginate through search results?

Use per_page to set the page size and page to walk forward, incrementing page until the result array is short or empty. SocialCrawl handles GitHub's search pagination behind that page number for you.

### How much does the GitHub Search API cost?

Each search costs 1 credit on the standard tier, regardless of how many results come back on the page. New accounts get 100 free credits with no credit card required, enough to run around 100 searches before you pay.

See the full GitHub API: https://www.socialcrawl.dev/platforms/github

## Pricing

- Standard endpoints: 1 credit per call
- Advanced endpoints: 5 credits per call
- Premium endpoints: 10 credits per call
- 100 free credits on signup, no credit card required. Cached responses cost 0 credits. Credit packs never expire.
- Full pricing: https://www.socialcrawl.dev/pricing

## Explore with AI

Questions this API answers, phrased for an AI assistant:

- How to search GitHub issues and PRs with an API
- What does the SocialCrawl GitHub Search API return?