Informationen zu primären Ratenbegrenzungen
GitHub beschränkt die Anzahl der REST-API-Anforderungen, die Sie innerhalb eines bestimmten Zeitraums vornehmen können. Dieses Limit trägt dazu bei, Missbrauch und Denial-of-Service-Angriffe zu verhindern, und stellt sicher, dass die API für alle Benutzer*innen verfügbar bleibt.
Einige Endpunkte, z. B. die Suchendpunkte, weisen restriktivere Begrenzungen auf. Weitere Informationen zu API-Endpunkten findest du unter REST-API-Endpunkte für die Ratenbegrenzung. Die GraphQL-API verfügt auch über eine separate primäre Ratenbegrenzung. Weitere Informationen findest du unter Ratenbegrenzungen und Knotengrenzwerte für die GraphQL-API.
Im Allgemeinen können Sie Ihre primäre Ratenbegrenzung für die REST-API basierend auf Ihrer Authentifizierungsmethode berechnen, wie unten beschrieben.
Primäre Ratenbegrenzung für nicht authentifizierte Benutzer
Sie können nicht authentifizierte Anforderungen vornehmen, wenn Sie nur öffentliche Daten abrufen. Nicht authentifizierte Anforderungen sind der ursprünglichen IP-Adresse und nicht der Person oder Anwendung zugeordnet, die Anforderungen erstellt.
Für nicht authentifizierte Anforderungen ermöglicht die primäre Ratenbegrenzung bis zu 60 Anforderungen pro Stunde.
Primäre Ratenbegrenzung für authentifizierte Benutzer
Sie können eine personal access token verwenden, um API-Anforderungen zu stellen. Außerdem können Sie eine OAuth app oder GitHub App autorisieren, die API-Anforderungen in Ihrem Namen erstellen kann.
Alle diese Anforderungen zählen zu deiner persönlichen Ratenbegrenzung von 5.000 Anforderungen pro Stunde. Anforderungen, die in deinem Namen von einer GitHub App im Besitz einer GitHub Enterprise Cloud-Organisation gestellt werden, weisen eine höhere Ratenbegrenzung von 15.000 Anforderungen pro Stunde auf. Ebenso haben Anforderungen, die in deinem Namen von einer OAuth app durchgeführt werden, die im Besitz einer GitHub Enterprise Cloud-Organisation ist bzw. von dieser genehmigt wird, eine höhere Rate von 15.000 Anforderungen pro Stunde, wenn du Mitglied der GitHub Enterprise Cloud-Organisation bist.
Primäre Ratenbegrenzung für GitHub App-Installationen
GitHub Apps, die sich mit einem Installationszugriffstoken authentifizieren, verwenden den minimalen Ratengrenzwert der Installation von 5.000 Anforderungen pro Stunde. Wenn sich die Installation in einer GitHub Enterprise Cloud-Organisation befindet, hat die Installation eine Ratenbegrenzung von 15.000 Anforderungen pro Stunde.
Bei Installationen, die sich nicht in einer GitHub Enterprise Cloud-Organisation befinden, wird die Ratenbegrenzung für die Installation mit der Anzahl der Benutzer und Repositorys skaliert. Installationen mit mehr als 20 Repositorys erhalten weitere 50 Anforderungen pro Stunde für jedes Repository. Installationen in einer Organisation mit mehr als 20 Benutzern erhalten weitere 50 Anforderungen pro Stunde für jeden Benutzer. Die Ratenbegrenzung darf nicht mehr als 12.500 Anforderungen pro Stunde betragen.
Primäre Ratenbegrenzungen für GitHub App-Benutzerzugriffstoken (im Gegensatz zu Installationszugriffstoken) werden durch die primären Ratenbegrenzungen für den authentifizierten Benutzer bestimmt. Diese Ratenbegrenzung wird mit allen Anforderungen kombiniert, die andere GitHub App or OAuth app im Namen dieses Benutzers vornehmen, sowie alle Anforderungen, die der Benutzer mit einer personal access token durchführt. Weitere Informationen findest du unter Primäre Ratenbegrenzung für authentifizierte Benutzer.
Ratenbegrenzungen für OAuth apps
Primäre Ratenbegrenzungen für OAuth-Zugriffstoken, die von einem OAuth app generiert werden, werden von den primären Ratenbegrenzungen für authentifizierte Benutzer bestimmt. Diese Ratenbegrenzung wird mit allen Anforderungen kombiniert, die andere GitHub App or OAuth app im Namen dieses Benutzers vornehmen, sowie alle Anforderungen, die der Benutzer mit einer personal access token durchführt. Weitere Informationen findest du unter Primäre Ratenbegrenzung für authentifizierte Benutzer.
OAuth-Apps können auch ihre Client-ID und den geheimen Clientschlüssel verwenden, um öffentliche Daten abzurufen. Zum Beispiel:
curl -u YOUR_CLIENT_ID:YOUR_CLIENT_SECRET -I https://api.github.com/meta
Bei diesen Anforderungen beträgt die Ratenbegrenzung 5.000 Anforderungen pro Stunde pro OAuth app. Wenn sich die App in einer GitHub Enterprise Cloud-Organisation befindet, hat die Installation eine Ratenbegrenzung von 15.000 Anforderungen pro Stunde.
Note
Füge niemals den geheimen Clientschlüssel deiner App in clientseitigen Code oder in Code ein, der auf einem Benutzergerät ausgeführt wird. Der geheime Clientschlüssel kann verwendet werden, um OAuth-Zugriffstoken für Benutzer zu generieren, die Ihre App autorisiert haben, Sie sollten daher den geheimen Clientschlüssel immer sicher aufbewahren.
Primäre Ratenbegrenzung für GITHUB_TOKEN in GitHub Actions
Du kannst das integrierte GITHUB_TOKEN verwenden, um Anforderungen in GitHub Actions-Workflows zu authentifizieren. Weitere Informationen findest du unter Automatische Tokenauthentifizierung.
Der Ratengrenzwert für GITHUB_TOKEN beträgt 1.000 Anforderungen pro Stunde pro Repository. Für Anforderungen an Ressourcen, die zu einem GitHub Enterprise Cloud-Konto gehören, beträgt der Grenzwert 15.000 Anforderungen pro Stunde pro Repository.
Informationen zu sekundären Ratenbegrenzungen
Zusätzlich zu den Primärratenbegrenzungen erzwingt GitHub sekundäre Ratenbeschränkungen, um Missbrauch zu verhindern und die API für alle Benutzer verfügbar zu halten.
Wenn Sie folgende Aktionen ausführen, kann es zu einer sekundären Ratenbegrenzung gehen:
- Zu hohe Anzahl gleichzeitiger Anforderungen. Es sind nicht mehr als 100 gleichzeitige Anforderungen zulässig. Dieser Grenzwert wird für die REST-API und die GraphQL-API freigegeben.
- Nehmen Sie zu viele Anforderungen an einen einzelnen Endpunkt pro Minute vor. Für REST-API-Endpunkte sind maximal 900 Punkte pro Minute zulässig und für den GraphQL-API-Endpunkt sind maximal 2 000 Punkte pro Minute zulässig. Weitere Informationen zu Punkten findest du unter Berechnen von Punkten für das sekundäre Ratenbegrenzungen.
- Nehmen Sie zu viele Anforderungen pro Minute vor. Maximal 90 Sekunden CPU-Zeit pro 60 Sekunden Echtzeit ist zulässig. Es kann nicht mehr als 60 Sekunden dieser CPU-Zeit für die GraphQL-API sein. Sie können die CPU-Zeit grob schätzen, indem Sie die Gesamtantwortzeit für Ihre API-Anforderungen messen.
- Nehmen Sie zu viele Anforderungen vor, die in kurzer Zeit zu viele Computeressourcen verbrauchen.
- Erstellen Sie in kurzer Zeit zu viele Inhalte für GitHub. Im Allgemeinen sind nicht mehr als 80 Anforderungen zum Generieren von Inhalten pro Minute und maximal 500 Anforderungen zur Inhaltsgenerierung pro Stunde zulässig. Einige Endpunkte weisen niedrigere Grenzwerte für die Inhaltserstellung auf. Zu den Grenzwerten für die Inhaltserstellung gehören Aktionen, die auf der GitHub-Webschnittstelle sowie über die REST-API und die GraphQL-API ausgeführt werden.
Diese Sekundärratenbegrenzungen können ohne Vorherige Ankündigung geändert werden. Es kann auch sein, dass Sie aus unbekannten Gründen auf eine sekundäre Ratenbegrenzung stoßen.
Berechnen von Punkten für die sekundäre Ratenbegrenzung
Einige sekundäre Ratenbegrenzungen werden durch die Punktwerte der Anforderungen bestimmt. Bei GraphQL-Anforderungen sind diese Punktwerte getrennt von den Punktwertberechnungen für die primäre Ratenbegrenzung.
| Anfordern | Punkte |
|---|---|
| GraphQL-Anforderungen ohne Mutationen | 1 |
| GraphQL-Anforderungen mit Mutationen | 5 |
Die meisten REST-API GET-, HEAD- und OPTIONS-Anforderungen | 1 |
Die meisten POST-, PATCH-, PUT- oder DELETE-Anforderungen über die REST-API | 5 |
Einige REST-API-Endpunkte haben einen anderen Kostenpunkt, der nicht öffentlich freigegeben wird.
Überprüfen des Status Ihrer Ratenbegrenzung
Sie können die Kopfzeilen verwenden, die mit jeder Antwort gesendet werden, um den aktuellen Status Ihrer primären Ratenbegrenzung zu ermitteln.
| Headername | Beschreibung |
|---|---|
x-ratelimit-limit | Die maximale Anzahl von Anforderungen, die Sie pro Stunde stellen dürfen. |
x-ratelimit-remaining | Die Anzahl der Anforderungen, die im aktuellen Ratenbegrenzungsfenster verbleiben. |
x-ratelimit-used | Die Anzahl der Anforderungen, die Sie im aktuellen Ratenbegrenzungsfenster gesendet haben. |
x-ratelimit-reset | Die Zeit in Sekunden seit der UTC-Epoche, zu der das aktuelle Ratenbegrenzungsfenster zurückgesetzt wird. |
x-ratelimit-resource | Die Ratenbegrenzungsressource, auf die die Anforderung angerechnet wird. Weitere Informationen zu den verschiedenen Ressourcen findest du unter REST-API-Endpunkte für die Ratenbegrenzung. |
Sie können auch den GET /rate_limit-Endpunkt aufrufen, um Ihre Ratenbegrenzung zu überprüfen. Das Aufrufen dieses Endpunkts zählt nicht zu Ihrer primären Ratenbegrenzung, kann aber auf Ihre sekundäre Ratenbegrenzung angerechnet werden. Weitere Informationen findest du unter REST-API-Endpunkte für die Ratenbegrenzung. Wenn möglich, sollten Sie die Antwortheader für die Ratenbegrenzung verwenden, anstatt die API aufzurufen, um Ihre Ratenbegrenzung zu überprüfen.
Es gibt keine Möglichkeit, den Status Ihrer sekundären Ratenbegrenzung zu überprüfen.
Überschreiten der Ratenbegrenzung
Wenn Sie Ihre primäre Ratenbegrenzung überschreiten, erhalten Sie eine 403- oder 429-Antwort, und der x-ratelimit-remaining-Header lautet 0. Sie sollten die Anforderung erst nach Ablauf der im x-ratelimit-reset-Header angegebenen Zeit wiederholen.
Wenn Sie eine sekundäre Ratenbegrenzung überschreiten, erhalten Sie eine 403- oder 429-Antwort und eine Fehlermeldung, die angibt, dass Sie eine sekundäre Ratenbegrenzung überschritten haben. Wenn der Antwortheader retry-after vorhanden ist, solltest du deine Anforderung erst nach Ablauf dieser Sekundenzahl erneut übermitteln. Wenn der x-ratelimit-remaining-Header 0 lautet, solltest du die Anforderung erst nach Ablauf der im x-ratelimit-reset-Header angegebenen UTC-Epochensekunden erneut senden. Warte andernfalls mindestens eine Minute, bevor du den Vorgang wiederholst. Wenn Ihre Anforderung aufgrund einer sekundären Ratenbegrenzung weiterhin fehlschlägt, warten Sie auf eine exponentiell steigende Zeitspanne zwischen Wiederholungen, und lösen Sie nach einer bestimmten Anzahl von Wiederholungen einen Fehler aus.
Wenn Sie weiterhin Anfragen stellen, während die Ratenbegrenzung eingeschränkt ist, kann dies zu einer Sperrung Ihrer Integration führen.
Unterhalb der Ratenbegrenzung bleiben
Sie sollten die bewährten Methoden befolgen, die Ihnen helfen, unter den Ratenbegrenzungen zu bleiben. Weitere Informationen findest du unter Bewährte Methoden für die Verwendung der REST-API.
Erhalten einer höheren Ratenbegrenzung
Wenn Sie sich eine höhere primäre Ratenbegrenzung wünschen, erwägen Sie, authentifizierte Anforderungen anstelle nicht authentifizierter Anforderungen zu erstellen. Authentifizierte Anforderungen haben eine wesentlich höhere primäre Ratenbegrenzung als nicht authentifizierte Anforderungen.
Wenn du ein personal access token zur Automatisierung in deiner Organisation verwendest, erwäge, ob stattdessen eine GitHub App funktioniert. Die Ratenbegrenzung für GitHub Apps mithilfe eines Installationszugriffstokens skaliert mit der Anzahl an Repositorys und Benutzern. Weitere Informationen findest du unter Informationen zum Erstellen von GitHub-Apps.
Wenn Sie GitHub Apps oder OAuth apps verwenden, sollten Sie ein Upgrade auf GitHub Enterprise Cloud in Erwägung ziehen. GitHub Apps oder OAuth apps haben höhere Ratenbegrenzungen für Organisationen, die GitHub Enterprise Cloud verwenden.