GitHub Scraper — Repos, Issues, PRs & Code

What is GitHub Scraper?

GitHub Scraper (repos, issues, PRs, code search and commits) is an Apify Actor for public GitHub data. It accepts one GitHub surface per run, such as a repository, search query, user login, or trending filter, and returns one flat record per result. Each record includes mode, type, url, and scrapedAt, plus mode-specific GitHub fields that support repo analysis, issue review, PR inspection, code search, contributor lookup, release tracking, README retrieval, commit history review, user profiling, and trending exploration.

Best fit and connected workflows

This Actor fits workflows that need one GitHub scraping tool with multiple routes:

• Repository research: use repo when a workflow starts from one public repository and needs a full metadata snapshot.
• Issue and PR review: use issues or prs when a workflow starts from a repo and needs lists, labels, comments, reviews, or review threads.
• Code discovery: use code-search when a workflow starts from a text query and needs code matches across GitHub.
• Contributor and release analysis: use contributors or releases when the workflow needs contributor profiles or release history from a repo.
• Documentation extraction: use readme when the workflow needs the repository README as markdown and rendered text.
• Commit inspection: use commits when the workflow needs commit history, and optionally file diffs.
• Profile review: use user when the workflow starts from a GitHub login and needs the profile plus repositories.
• Trend scanning: use trending when the workflow needs trending repositories by language and timeframe.

Practical scenario

A developer advocate named Mina starts with apify/actors-mcp-server and wants to prepare a short update for her team. She runs the Actor in prs mode with state: "closed" and includeReviews: true. The returned dataset record includes the PR url, type: "pr", and scrapedAt, plus PR-specific fields for review state and review comments. Mina uses the review state and PR URL to pick one merged change for a deeper read, then shares the PR link in her team note.

Input fields

Field	Type	Used in	Description
mode	string	all modes	Selects one GitHub surface to scrape. One mode per run.
repo	string	repo, issues, prs, contributors, releases, readme, commits	GitHub repository in owner/name format, or a full GitHub repo URL.
query	string	repo-search, code-search	GitHub search query with qualifiers such as language:, stars:, org:, path:, and extension:.
user	string	user	GitHub user or organization login.
language	string	trending	Language filter for trending mode.
timeframe	string	trending	Trending window: daily, weekly, or monthly.
state	string	issues, prs	Issue or PR state filter: open, closed, or all.
since	string	issues, prs, commits	ISO 8601 date for returning items updated or created at or after the given point.
maxResults	integer	all modes	Maximum number of records to return.
includeComments	boolean	issues, prs	Includes comments for each issue or PR.
includeReviews	boolean	prs	Includes reviews and review comments for each PR.
includeFiles	boolean	commits	Includes file diffs for each commit.

Focused JSON input example

{
  "mode": "prs",
  "repo": "vercel/next.js",
  "state": "closed",
  "includeReviews": true,
  "since": "2026-01-01",
  "maxResults": 25
}

Output fields

The dataset returns one flat record per result. Every record has mode, type, url and scrapedAt; the other fields depend on the mode.

Mode → type	Main fields
repo, repo-search → repo	fullName, description, homepage, language, topics, stars, forks, watchers, openIssues, license, archived, defaultBranch, createdAt, pushedAt, languages, latestRelease
issues → issue	repo, number, title, state, stateReason, author, assignees, labels, milestone, commentCount, comments (with includeComments), body, createdAt, closedAt
prs → pr	repo, number, title, state, draft, merged, mergedAt, author, reviewers, labels, head, base, additions, deletions, changedFiles, commits, reviewCommentCount, reviews (with includeReviews), comments
commits → commit	repo, sha, message, author, committedAt, parents, verified, stats, files (with includeFiles)
code-search → code-match	repository, file path and match URL for each code hit
contributors, releases, readme, user, trending	contributor profiles, release notes and assets, README markdown and text, user profile plus repositories, trending repositories

A missing repository returns one type: "not-found" record with a _note explaining what to fix, instead of an empty run.

Example record (a real repo mode result, trimmed)

{
  "mode": "repo",
  "type": "repo",
  "owner": "react",
  "name": "react",
  "fullName": "react/react",
  "description": "The library for web and native user interfaces.",
  "url": "https://github.com/react/react",
  "homepage": "https://react.dev",
  "language": "JavaScript",
  "topics": [
    "declarative",
    "frontend",
    "javascript",
    "library",
    "react",
    "ui"
  ],
  "stars": 250881,
  "forks": 51430,
  "watchers": 6604,
  "openIssues": 1411,
  "defaultBranch": "main",
  "license": "MIT",
  "archived": false,
  "createdAt": "2013-05-24T16:15:54Z",
  "pushedAt": "2026-10-02T21:13:55Z",
  "languageBreakdown": [
    "JavaScript",
    "Rust",
    "TypeScript"
  ],
  "latestRelease": {
    "tagName": "v19.3.0",
    "name": "19.3.0 (September 9, 2026)",
    "publishedAt": "2026-09-09T18:01:33Z",
    "url": "https://github.com/react/react/releases/tag/v19.3.0"
  },
  "scrapedAt": "2026-10-04T15:13:55.579Z"
}

How it works

This Actor uses GitHub's public REST API for the selected mode, plus the public GitHub trending page for trending mode. The input schema defines 11 modes: repo, repo-search, issues, prs, code-search, contributors, releases, readme, commits, user, and trending. Repository-based modes normalize owner/name input, and full repository URLs are accepted for the repo field. The output dataset stays flat so downstream tools and agents can read it easily. OUTPUT and RUN_SUMMARY in key-value storage state whether the run was complete, partial, valid but empty, invalid, or failed upstream.

Pricing

This Actor uses Apify Pay per event. Apify platform usage is included in the event price, so you pay only for the events below. Open the Pricing tab in Apify Console for the current event prices.

Event	When it is charged
apify-actor-start	Automatically at run start, including runs that return no useful result or fail after starting. The event count depends on the memory selected for the run.
result	Each useful simple record persisted to the dataset: repos, issues or PRs without comments/reviews, commits without file diffs, contributors, releases, README, users, trending repos.
deep-result	Each useful heavier record persisted to the dataset: code-search matches, issues with comments, PRs with comments or reviews, commits with file details.

For example, a run that returns twenty simple results is billed for one start event plus twenty result events at the default memory setting. The same twenty PRs fetched with includeReviews: true are twenty deep-result events. A valid empty search, invalid input, or GitHub rate limit can still incur the start charge but no result charge. A run spending limit controls the maximum event charges; check the Pricing tab for its current minimum. Platform usage is included, so there is no separate usage charge.

Use with AI agents (MCP)

This Actor is Apify MCP-ready and usable through Apify MCP as khadinakbar/github-deep-scraper. It is a tool for retrieving structured GitHub data by mode, so an agent can request exactly the surface it needs and then read the dataset rows returned by the run.

Tool description: fetch public GitHub records for a chosen mode, then read the resulting dataset items and OUTPUT / RUN_SUMMARY run outcome records.

Fetch the closed pull requests for vercel/next.js since the start of the year, include reviews, and return the dataset items with their GitHub URLs and scrape timestamps.

When interpreting results, treat useful dataset rows as GitHub entities or search results; a diagnostic row reports a missing or invalid input/target and has no result charge. The shared fields identify the source mode, record type, canonical URL, and fetch time. For broader runs, use maxResults to bound how many rows the agent receives. For heavier modes and options, such as code search, PR reviews, PR comments, and commit file details, the deep-result event rate applies. Inspect OUTPUT or RUN_SUMMARY for the terminal outcome and charge counts.

Apify API example

import { ApifyClient } from "apify-client";

const client = new ApifyClient({
  token: process.env.APIFY_TOKEN,
});

const run = await client.actor("khadinakbar/github-deep-scraper").call({
  mode: "repo",
  repo: "facebook/react",
  maxResults: 1,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items);

Best results and outcome guidance

Use repo when the workflow starts from one repository and needs a broad snapshot. Use repo-search when the workflow starts from a topic, stack, or qualifier query. Use issues and prs when the workflow needs discussion context, labels, reviews, or thread comments. Use commits when the workflow needs change history, and enable file diffs when reasoning about touched files matters. Use trending when the workflow needs a current list of popular repositories by language and timeframe. Set maxResults to the smallest number that covers the task so the run stays focused.

Continue the workflow

• Then use Google Play Store All-in-One Scraper — Apps, Reviews, Charts to extend GitHub Deep Scraper — Repos, Issues, PRs, Code Search, Commits with a neighboring software ecosystem research source when the brief calls for Google Play data.
• Then use App Store Reviews Scraper - iOS & macOS Ratings to extend GitHub Deep Scraper — Repos, Issues, PRs, Code Search, Commits with a neighboring software ecosystem research source when the brief calls for App Store data.

Design note

I found that the dataset contract is intentionally flat: every record includes mode, type, url, and scrapedAt, while the rest of the fields vary by mode.

FAQ

Which GitHub surface should I use for a full repository snapshot?
Use repo for one repository's full metadata.

Which mode is suited to finding repositories by topic or qualifier?
Use repo-search and pass a GitHub search query in the query field.

Which mode should I use for issue threads or PR conversations?
Use issues or prs, and turn on includeComments when you want thread context.

How do I inspect code across GitHub?
Use code-search with a search query. The live contract marks this mode as requiring the GITHUB_TOKEN environment variable.

How do I get a repository README?
Use readme with the repository name in owner/name format.

How do I get commit history with file diffs?
Use commits and set includeFiles: true when file-level reasoning matters.

How do I get trending repositories for a language?
Use trending with language and timeframe.

Responsible use

Use this Actor for public GitHub data and keep your usage aligned with GitHub's terms and applicable data-protection rules. Review the live Pricing tab before larger runs, especially when using result-heavy modes or options that add comments, reviews, or file diffs.