GitHub Repos, User & Trending scrapen in 2026 (API & Python)

Am schnellsten scrapst du 2026 GitHub, indem du eine strukturierte API aufrufst, die normalisiertes JSON zurückgibt — Repositories, User, Organisationen, Contributors, Stargazers, Sprach-Aufschlüsselungen, Releases und Trending — statt die stündliche Quota der offiziellen API aufzubrauchen oder githubs client-gerenderte Seiten zu parsen. GitHub ist in dieser Serie ungewöhnlich: Es hat eine wirklich leistungsfähige offizielle API, die eigentliche Frage ist also, wann die Rate-Limits Scraping zur besseren Wahl machen. Dieser Guide behandelt alle drei Ansätze, was jeder liefert, wo jeder scheitert und die rechtlichen Grundlagen.

Warum GitHub scrapen?

Öffentliche GitHub-Daten treiben eine ganze Kategorie von Entwickler-, Recruiting- und Marktarbeit an:

• Developer-Sourcing & Recruiting — finde und ranke User nach Sprache, Standort und Contribution-Historie.
• Open-Source-Abhängigkeits- & Wettbewerber-Tracking — beobachte Stars, Forks, Releases und Contributor-Fluktuation bei den Projekten, von denen du abhängst oder mit denen du konkurrierst.
• Tech-Trend- & Marktforschung — verfolge Trending-Repos und -Sprachen, um zu sehen, wohin sich das Ökosystem bewegt.
• Developer Relations & Outreach — baue gezielte Listen von Maintainern und Stargazers relevanter Projekte.
• AI- / LLM-Pipelines — speise Repo-Metadaten, READMEs und Release-Notes in Retrieval- und Analyse-Workflows ein.

Ist es legal, GitHub zu scrapen?

Option 1: DIY in Python (und warum es scheitert)

Die meisten DIY-Ansätze starten mit der offiziellen REST API über requests (oder PyGithub):

import requests

h = {"Authorization": "Bearer YOUR_GH_TOKEN", "Accept": "application/vnd.github+json"}
repo = requests.get("https://api.github.com/repos/torvalds/linux", headers=h).json()
contributors = requests.get("https://api.github.com/repos/torvalds/linux/contributors",
                            headers=h, params={"per_page": 100}).json()

Für kleine Abrufe funktioniert es, dann stößt es an Wände:

• Die Rate-Limit-Quota. Unauthentifizierte Requests sind bei 60/Stunde pro IP gedeckelt; ein Token hebt den Core auf 5.000/Stunde an. 1.000 Repos mit je ~5 Calls zu analysieren (Detail, Contributors, Languages, Releases, Stargazers) verbrennt die gesamte stündliche Quota in einem einzigen Scan.
• Die Suche ist strenger und gedeckelt. Die Search API läuft mit ~30 Requests/Minute und gibt höchstens 1.000 Ergebnisse pro Query zurück — du kannst also nicht über die ersten 1.000 Treffer hinaus blättern, egal wie viele existieren.
• Secondary Rate-Limits. Stoßweise oder parallele Requests lösen Abuse-Detection-Limits mit 403ern und Retry-After aus, du brauchst also Backoff und sorgfältige Nebenläufigkeit.
• HTML-Parsing ist schlimmer. Auf requests + BeautifulSoup auf github.com auszuweichen trifft auf client-seitiges Rendering und häufigen Layout-Drift und löst trotzdem dieselbe Anti-Bot-Abwehr aus.

Option 2: No-Code-Tools

Visuelle Extraktoren und Marktplatz-»GitHub«-Actors exportieren CSV/JSON und eignen sich für einmalige Abrufe, aber in einer In-Product-Pipeline mit vorhersehbaren Feldern sind sie umständlich, und sie erben dieselben Rate-Limit- und Pagination-Grenzen.

Option 3: Eine strukturierte GitHub API

Für wiederholbare Workflows gibt eine strukturierte GitHub API normalisiertes JSON zurück, ohne Token-Jonglieren oder Backoff, das du verwalten musst. Suche, dann reichere an:

curl "https://api.crawlora.net/api/v1/github/search/repositories?q=web+scraping&sort=stars" \
  -H "x-api-key: $CRAWLORA_API_KEY"

In Python — Repos werden über owner/repo angesprochen, User über login:

import requests
h = {"x-api-key": "YOUR_API_KEY"}
base = "https://api.crawlora.net/api/v1"

# 1) Search repositories (paginated: page / per_page)
hits = requests.get(f"{base}/github/search/repositories", headers=h,
                    params={"q": "web scraping", "sort": "stars", "per_page": 50}).json()["data"]

# 2) Full detail for one repo
repo = requests.get(f"{base}/github/repo/torvalds/linux", headers=h).json()["data"]

Die Suche gibt eine Gesamtzahl plus paginierte Items zurück (die Felder sind beispielhaft — prüfe die docs):

{
  "code": 200,
  "msg": "OK",
  "data": {
    "total_count": 18742,
    "items": [
      { "full_name": "torvalds/linux", "owner": "torvalds", "language": "C", "stars": 180000, "forks": 53000, "topics": ["kernel", "linux"], "license": "GPL-2.0" }
    ]
  }
}

Derselbe Key erreicht Contributors, Stargazers, Languages, Releases, User und Trending:

contributors = requests.get(f"{base}/github/repo/torvalds/linux/contributors", headers=h,
                            params={"per_page": 100}).json()["data"]   # login, contributions
langs = requests.get(f"{base}/github/repo/torvalds/linux/languages", headers=h).json()["data"]  # bytes per language
user = requests.get(f"{base}/github/user/torvalds", headers=h).json()["data"]                    # name, company, followers
trending = requests.get(f"{base}/github/trending", headers=h,
                        params={"language": "python", "since": "daily"}).json()["data"]          # stars_today

Übergib page/per_page, um Contributors und Stargazers durchzugehen, language/since für Trending, speichere eine Zeile pro Repo oder User und rufe die Daten nach einem Zeitplan erneut ab, um Stars, Releases und Contributor-Fluktuation über die Zeit zu verfolgen.

Was du sammeln kannst

• Repositories — name, full_name, owner, description, language, topics, stars, forks, watchers, open_issues, license, default_branch, pushed_at.
• Repo-Graph — Contributors (login, contributions), Stargazers, Forks, Sprach-Byte-Aufschlüsselung und Releases (tag_name, name, published_at, author).
• Suche — Repositories und User, jeweils mit total_count und paginierten Items.
• User & Orgs — Profil (login, name, company, location, blog, followers, public_repos, social_accounts), die öffentlichen Repos eines Users oder einer Org sowie die jüngsten öffentlichen Events und gepinnten Repos eines Users.
• Trending — Trending-Repositories (mit stars_today) und Trending-Entwickler, nach Sprache und Zeitfenster.

Alles sind öffentliche GitHub-Daten — bleib bei öffentlichen, sachlichen Feldern.

Einschränkungen und häufige Herausforderungen

• Die Rate-Limits der offiziellen API sind der eigentliche Blocker. 60/Stunde unauthentifiziert, 5.000/Stunde mit einem Token und Suche mit ~30/Minute, gedeckelt auf 1.000 Ergebnisse — eine strukturierte API fängt die Drosselung und das Token-Management hinter einem Key ab.
• Die Suche deckelt bei 1.000 Ergebnissen. Kein Endpoint blättert über die ersten 1.000 Treffer einer Query hinaus; grenze die Query ein (nach Sprache, Stars oder Datum), um große Ergebnismengen zu sharden.
• Manche Listen sind abgeschnitten. GitHub deckelt Contributor- und ähnliche Listen, sehr große Repos geben also nicht jeden Contributor zurück — plane um die Grenze herum.
• Profile enthalten personenbezogene Daten. Namen, Unternehmen, Standorte und verknüpfte Social-Accounts sind unter DSGVO/CCPA personenbezogen — sammle öffentliche, sachliche Felder mit einer Rechtsgrundlage.

Wo das eingesetzt wird

• Developer-Sourcing — ranke User nach Sprache, Standort und Contribution-Historie für Recruiting oder Dev-Rel.
• Company- & Tech-Enrichment — kartiere die Repos, Sprachen und den Release-Rhythmus einer Org. Siehe den Use Case company data enrichment.
• OSS-Trend-Tracking — beobachte Trending-Repos und -Sprachen, um zu erkennen, wohin sich das Ökosystem bewegt.

Sources

Leg los mit dem Sammeln

Probier es erst kostenlos aus: jage eine beliebige öffentliche URL durch den Free Web Scraper oder prüfe mit dem Anti-Bot Checker, ob eine Website Bots blockiert — ohne Anmeldung.

Teste die Endpoints im Playground, prüfe das Schema in den API docs und sieh dir die pricing an. Siehe auch how to choose a web scraping API und is web scraping legal.