The GitHub repository search API runs a repository search and returns one row per result — owner/name, description, primary language, star count, topics, the archived flag and the last-update timestamp, ranked in the order GitHub returned them.
It reads the server-rendered search results page rather than the REST API, which has one concrete consequence: there is no personal access token to mint and you are not subject to the unauthenticated API's ceiling of ten requests a minute. GitHub's full search grammar still works, so language:python, stars:>1000 and the rest of the qualifiers narrow the set exactly as they would on the site.
$0.0005 per delivered repository, up to 50 repositorys per run. Nothing delivered means nothing charged.
You post a query and, optionally, a sort of best_match, stars or updated. The query is passed through untouched, so any qualifier you would type into GitHub's own search box — org:, topic:, language:, stars:>500 — behaves the same here.
Each results page carries ten repositories, and the collector pages through them up to your requested max_results, parsing each card into a flat row. Two points are worth internalising:
api.github.com, the 10-request-per-minute unauthenticated cap and the 30-per-minute authenticated search cap simply do not apply — your ceiling is your QuantumProxies plan's request rate.rank field records the 1-based position GitHub assigned, so a relevance-sorted run stays meaningful after you store it.Chasing repos that only surface in write-ups rather than search? The Google search collector is the companion for that kind of discovery.
The only required input is query, and GitHub's search syntax is fair game inside it. sort chooses between best-match, most-starred and recently-updated ordering. max_results caps the run at up to 50 repositories, and because results arrive ten to a page it also controls how many pages get fetched.
Each repository is one flat row. repo is the canonical owner/name string, split out into owner and name for convenience. stars is an integer and topics a string array, so you can filter on popularity and tags without post-processing. archived flags repositories GitHub has frozen, and updated_at is an ISO 8601 timestamp you can sort or diff directly.
$0.0005 per delivered repository ($0.50 per 1,000). Nothing delivered means nothing charged, and the $2 monthly free credit covers roughly 4,000 repositorys here. Volume tiers take up to 30% off.
$0.0005 per delivered repository — 50 cents per 1,000 — which makes this the cheapest collector in the catalogue and a natural fit for broad, repeated sweeps. Scanning 100,000 repositories across a set of queries is $50 at list price, and volume tiers take it lower.
Rows are billed only when they arrive, so a query that matches nothing costs nothing. The free monthly allowance of $2 covers about 4,000 repositories, and GET /v1/scraper/collectors returns the exact per-row price your key is charged.
GitHub's own GET /search/repositories is the documented route and it returns richer JSON than a search page does. Its constraints are about throughput. Unauthenticated it allows ten requests a minute; authenticated it lifts to thirty, plus a secondary abuse limiter; and every search — official or not — stops at 1,000 results, so a query with 40,000 matches is only ever paginated 1,000 deep. Teams doing wide inventory or trend work run into those walls quickly.
This collector trades the API's extra JSON fields for freedom from the token and the per-minute cap: it reads the same ranked list a logged-out visitor sees, at your plan's request rate. When you need the fields only the API exposes for a specific repo, call the API for those; when you need breadth, read the search page.
Fetching one search page is trivial. Keeping a fleet of them flowing is not:
github.com/search from one IP and you get throttled or served an interstitial; without rotating exits the run stalls after a few pages.Handing it over gives you a typed schema and a bill that tracks delivered rows. If you would rather keep your own crawler and just want dependable exits under it, the residential proxies are the same network this collector runs on.
Sweep topic: and language: queries to build an inventory of every repository in an ecosystem, with stars and updated_at to rank maintenance and adoption.
Track how many repositories mention a framework and how their star counts move over time, using cheap repeated runs rather than a token budget you have to nurse.
Filter with stars:>500 and read archived and updated_at to separate live, well-supported projects from abandoned ones before you depend on them.
One run returns up to 50 repositories — GitHub's search itself caps any query at 1,000 results, so very broad queries are best narrowed with qualifiers rather than paged endlessly. Runs are independent and parallelise up to your plan's rate limit, 60 requests a minute on pay-as-you-go and up to 1,200 on the top tier. This collector returns the search-card fields; it does not clone the repository or read file contents.
Legally: repository listings are public and reading public data is generally lawful in most places, but GitHub's terms govern automated access and your downstream use carries its own obligations, especially around licences. This is not legal advice — get advice for your specific case.
GitHub's REST API is free but throttled — ten requests a minute unauthenticated, thirty for authenticated search — and it needs a token. This collector has no token and no per-minute API cap, and it ships with a $2 monthly allowance, about 4,000 repositories at $0.0005 each, before you pay anything.
No. Because results are read from the public search page rather than api.github.com, there is no token to create and no OAuth app to register. Your QuantumProxies key is the only credential the request needs.
Yes. The query is forwarded to GitHub unchanged, so qualifiers like language:python, stars:>1000, topic: and org: all filter exactly as they do in the site's own search box.
Up to 50 per run, and GitHub caps any single search at 1,000 results total. For a category larger than that, split it with qualifiers — by language, by star range or by topic — and run each slice.