Ratenbegrenzungen für die REST-API

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 diesen 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 Abfragegrenzwerte 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 Ihrem Namen von einer GitHub App im Besitz einer GitHub App-Organisation gestellt werden, weisen eine höhere Ratenbegrenzung von 15.000 Anforderungen pro Stunde auf. Ebenso haben Anforderungen, die in Ihrem Auftrag von einem OAuth app durchgeführt werden, das im Besitz einer GitHub Enterprise Cloud Organisation ist oder von ihr genehmigt wurde, ein höheres Limit von 15.000 Anforderungen pro Stunde, wenn Sie Mitglied der GitHub Enterprise Cloud Organisation sind. Anforderungen von einer App mit höheren Grenzwerten verringern jedoch das verbleibende Budget, das für Authentifizierungsmethoden mit niedrigeren Grenzwerten verfügbar ist. Wenn eine App mit einem Anforderungslimit von 15.000 beispielsweise 10.000 Anforderungen in Ihrem Auftrag durchführt, haben Sie das Budget von 5.000 Anforderungen für Ihre personal access tokens ausgeschöpft, obwohl die App noch 5.000 Anforderungen übrig hat.

Primärratenlimit für Git LFS-Zugriff

API-Anforderungen sind erforderlich, wenn du Git LFS-Inhalte hoch- oder herunterlädst. Diese zählen zu einem separaten Rate-Limit-Topf mit einer Beschränkung von 300 Anfragen pro Minute für nicht authentifizierte Anfragen und 3.000 Anfragen pro Minute für authentifizierte Anfragen.

Git LFS verwendet eine Batch-API, die standardmäßig 100 Git LFS-Objekte pro API-Anforderung verarbeitet. Das bedeutet, dass nicht authentifizierte Benutzer 30.000 Git-LFS-Objekte pro Minute herunterladen und authentifizierte Benutzer 300.000 Git LFS-Objekte pro Minute hochladen/herunterladen können.

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 der Installation anhand der Anzahl von Benutzenden 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 finden Sie unter Ratenbegrenzungen für die REST-API.

Primäre Ratenbegrenzung 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.

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 Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.

Die Ratenbegrenzung 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 die Ratenbegrenzung von 15.000 Anforderungen pro Stunde pro Repository.

Informationen zu sekundären Ratenbeschränkungen

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, könnten Sie auf eine sekundäre Ratenbeschränkung stoßen:

•         _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](#calculating-points-for-the-secondary-rate-limit).
  

•         _Stellen Sie zu viele Anfragen pro Minute._ 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.
  

•         _Nehmen Sie in kurzer Zeit zu viele OAuth-Zugriffstokenanforderungen vor._ Für GitHub Apps und OAuth apps sind maximal 2.000 OAuth-Zugriffstokenanforderungen pro Stunde zulässig.
  

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.

Anfrage	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 verbleibenden Anfragen im aktuellen Zeitfenster für die Ratenbegrenzung.
x-ratelimit-used	Die Anzahl der Anforderungen, die Sie im aktuellen Ratenbegrenzungsfenster gesendet haben.
x-ratelimit-reset	Der Zeitpunkt, zu dem das aktuelle Ratenbegrenzungsfenster zurückgesetzt wird, angegeben in UTC-Epochensekunden.
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, sollten Sie Ihre 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 Sie einer Ratenbegrenzung unterliegen, kann dies zu einer Blockierung 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.

Erhöhung des Ratenlimits

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 in deiner Organisation einen personal access token für die Automatisierung verwendest, überlege, ob nicht stattdessen ein GitHub App funktioniert. Das Limit für GitHub Apps mit einem Zugriffstoken für die Installation skaliert mit der Anzahl der Repositories und der Anzahl der Benutzer in der Organisation. Siehe 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.