À propos des limites de débit primaire
GitHub limite le nombre de requêtes d'API REST que vous pouvez présenter dans un laps de temps donné. Cette limite permet d'éviter la mauvaise utilisation et les attaques par déni de service, et garantit que l'API reste disponible pour tous les utilisateurs.
Les limites de certains points de terminaison, comme les points de terminaison de recherche, sont plus restrictives. Pour en savoir plus sur ces points de terminaison, reportez-vous à « Points de terminaison d’API REST pour les limites de débit. » L'API GraphQL a également une limite de débit primaire distincte. Consultez « Limites de débit et limites de Node pour l’API GraphQL ».
Pour en savoir plus sur l’affichage de l’activité d’API d’une organisation, y compris les demandes qui ont dépassé les limites de débit principal, consultez «Visualisation des informations sur l'API dans votre organisation».
En général, vous pouvez calculer votre limite de débit primaire pour l'API REST en fonction de votre méthode d'authentification, comme décrit ci-dessous.
Limite de débit primaire pour les utilisateurs non authentifiés
Vous pouvez présenter des requêtes non authentifiées si vous ne recherchez que des données publiques. Les requêtes non authentifiées sont associées à l'adresse IP d'origine, non pas à l'utilisateur ou à l'application à l'origine de la requêtes.
La limite de débit primaire pour les requêtes non authentifiées est de 60 requêtes par heure.
Limite de débit primaire pour les utilisateurs authentifiés
Vous pouvez utiliser un personal access token pour présenter des requêtes d'API. En outre, vous pouvez autoriser une GitHub App ou une OAuth app, qui peut alors présenter des requêtes d'API en votre nom.
Toutes ces requêtes sont prises en compte dans votre limite personnelle de 5 000 requêtes par heure. Les requêtes présentées en votre nom par une GitHub App appartenant à une organisation GitHub Enterprise Cloud ont une limite de débit plus élevée de 15 000 requêtes par heure. De même, les requêtes présentées en votre nom par une OAuth app détenue ou approuvée par une organisation GitHub Enterprise Cloud ont une limite de débit plus élevée de 15 000 requêtes par heure si vous êtes membre de l'organisation GitHub Enterprise Cloud.
Limite du débit primaire pour les installations de GitHub App
Les GitHub Apps qui s'authentifient avec un jeton d'accès d'installation utilisent la limite de débit minimale de l'installation, soit 5 000 requêtes par heure. Si l'installation est sur une organisation GitHub Enterprise Cloud, l'installation a une limite de débit de 15 000 requêtes par heure.
Pour les installations qui ne sont pas sur une organisation GitHub Enterprise Cloud, la limite de débit pour l'installation sera fonction du nombre d'utilisateurs et de référentiels. Les installations qui ont plus de 20 référentiels reçoivent 50 requêtes supplémentaires par heure pour chaque référentiel. Les installations d'une organisation comptant plus de 20 utilisateurs reçoivent 50 requêtes supplémentaires par heure et par utilisateur. La limite de débit ne peut pas dépasser 12 500 requêtes par heure.
Les limites de débit primaires pour les jetons d'accès utilisateur GitHub App (par opposition aux jetons d'accès à l'installation) sont dictées par les limites de débit primaires pour l'utilisateur authentifié. Cette limite de débit est combinée avec toutes les requêtes qu'une autre GitHub App ou OAuth app présente au nom de cet utilisateur et toutes les requêtes que l'utilisateur présente avec un personal access token. Consultez « Limite de débit primaire pour les utilisateurs authentifiés ».
Limite du débit primaire pour OAuth apps
Les limites de débit primaires pour les jetons d'accès OAuth générés par une OAuth app sont dictées par les limites de débit primaires pour les utilisateurs authentifiés. Cette limite de débit est combinée avec toutes les requêtes qu'une autre GitHub App ou OAuth app présente au nom de cet utilisateur et toutes les requêtes que l'utilisateur présente avec un personal access token. Consultez « Limite de débit primaire pour les utilisateurs authentifiés ».
Les applications OAuth peuvent également utiliser leur identifiant et leur secret client pour récupérer des données publiques. Par exemple :
curl -u YOUR_CLIENT_ID:YOUR_CLIENT_SECRET -I https://api.github.com/meta
Pour ces requêtes, le débit limite est de 5 000 requêtes par heure et par OAuth app. Si l'application appartient à une organisation GitHub Enterprise Cloud, le débit limite est de 15 000 requêtes par heure.
Remarque : n'incluez jamais le secret client de votre application dans le code côté client ou dans le code qui s'exécute sur l'appareil de l'utilisateur. Le secret client peut être utilisé pour générer des jetons d'accès OAuth pour les utilisateurs qui ont autorisé votre application. Par conséquent, vous devez toujours garder le secret client sécurisé.
Limite de débit primaire pour GITHUB_TOKEN dans GitHub Actions
Vous pouvez utiliser le jeton GITHUB_TOKEN intégré pour authentifier les demandes dans des workflow GitHub Actions. Consultez « Authentification par jeton automatique ».
La limite de débit pour GITHUB_TOKEN est de 1 000 requêtes par heure et par référentiel.
À propos des limites de débit secondaires
Outre les limitations de débit primaires, GitHub applique les limitations de débit secondaires pour éviter les abus et de conserver l’API disponible pour tous les utilisateurs.
Vous pouvez rencontrer une limitation de débit secondaire si vous :
- Effectuez trop de demandes simultanées. Plus de 100 requêtes simultanées ne sont autorisées. Cette limite est partagée entre l’API REST et l’API GraphQL.
- Effectuez trop de demandes à un point de terminaison unique par minute. Plus de 900 points par minute sont autorisés pour les points de terminaison d’API REST, et pas plus de 2 000 points par minute sont autorisés pour le point de terminaison de l’API GraphQL. Pour plus d’informations sur les points, consultez « Calcul des points pour la limitation de débit secondaire ».
- Effectuez trop de demandes par minute. Plus de 90 secondes de temps processeur par 60 secondes de temps réel sont autorisées. Plus de 60 secondes de ce temps processeur peuvent être pour l’API GraphQL. Vous pouvez estimer approximativement le temps processeur en mesurant le temps de réponse total pour vos demandes d’API.
- Effectuez trop de requêtes qui consomment un nombre excessif de ressources de calcul pendant une courte période.
- Créez trop de contenu sur GitHub dans un court laps de temps. En général, pas plus de 80 demandes de génération de contenu par minute et pas plus de 500 demandes de génération de contenu par heure ne sont autorisées. Certains points de terminaison contiennent des limites de création de contenu inférieures. Les limites de création de contenu incluent les actions effectuées sur l’interface web GitHub ainsi que via l’API REST et l’API GraphQL.
Ces limitations de débit secondaires sont susceptibles de changer sans préavis. Vous pouvez également rencontrer une limitation de débit secondaire pour des raisons non déclarées.
Calcul de points pour la limitation de débit secondaire
Certaines limitations de débit secondaires sont déterminées par les valeurs de points des demandes. Pour les demandes GraphQL, ces valeurs de point sont distinctes des calculs de valeurs de point pour la limitation de débit primaire.
| Requête | Points |
|---|---|
| Demandes GraphQL sans mutations | 1 |
| Demandes GraphQL avec mutations | 5 |
La plupart des demandes GET, HEAD et OPTIONS de l’API REST | 1 |
La plupart des demandes POST, PATCH, PUT ou DELETE de l’API REST | 5 |
Certains points de terminaison d’API REST comportent un coût de point différent qui n’est pas partagé publiquement.
Vérification de l'état de votre limite de débit
Vous pouvez utiliser les en-têtes envoyés avec chaque réponse pour déterminer l'état actuel de votre limite de débit primaire.
| Nom de l'en-tête | Description |
|---|---|
x-ratelimit-limit | Nombre maximal de requêtes autorisées par heure |
x-ratelimit-remaining | Nombre de requêtes restantes dans la fenêtre de limite de débit actuelle |
x-ratelimit-used | Nombre de requêtes présentées dans la fenêtre de limite de débit actuelle |
x-ratelimit-reset | Heure à laquelle la fenêtre de limite de débit actuelle se réinitialise en secondes d'époque UTC. |
x-ratelimit-resource | Ressource de la limite de débit par rapport à laquelle la requête a été comptabilisée. Pour en savoir plus sur les différentes ressources, reportez-vous à « Points de terminaison d’API REST pour les limites de débit. » |
Vous pouvez également contacter le point de terminaison GET /rate_limit afin de vérifier votre limite de débit. L'appel de ce point de terminaison n'est pas pris en compte dans votre limite de débit primaire, mais il peut l'être dans votre limite de débit secondaire. Consultez « Points de terminaison d’API REST pour les limites de débit ». Dans la mesure du possible, il est préférable d'utiliser les en-têtes de réponse relatifs à la limite de débit plutôt que d'appeler l'API pour vérifier votre limite de débit.
Il n'existe pas de moyen de vérifier l'état de votre limite de débit secondaire.
Dépassement de la limite de débit
Si vous dépassez votre limite de débit primaire, vous recevrez une réponse 403 ou 429 et l'en-tête x-ratelimit-remaining sera 0. Vous ne devez réessayer votre requête qu'après le délai indiqué par l'en-tête x-ratelimit-reset.
Si vous dépassez une limite de débit secondaire, vous recevrez une réponse 403 ou 429 et un message d'erreur indiquant que vous avez dépassé une limite de débit secondaire. Si l'en-tête de réponse retry-after est présent, vous ne devez pas réessayer votre demande avant le nombre de secondes spécifié. Si l'en-tête x-ratelimit-remaining est 0, vous ne devez pas réessayer votre demande avant la durée spécifiée par l'en-tête x-ratelimit-reset (en secondes UTC). Sinon, attendez au moins une minute avant de réessayer. Si votre demande continue d'échouer en raison d'une limite de débit secondaire, attendez une durée exponentiellement croissante entre les nouvelles tentatives et levez une erreur après un nombre spécifique de nouvelles tentatives.
La poursuite des demandes pendant que vous êtes limité peut entraîner l'interdiction de votre intégration.
Rester en dessous de la limite de débit
Vous devez suivre les meilleures pratiques pour vous aider à rester en dessous des limites de débit. Consultez « Meilleures pratiques pour utiliser l'API REST ».
Vous pouvez également parcourir le journal d'audit pour voir les requêtes d'API. Ce journal peut vous aider à résoudre les problèmes d'intégrations qui dépassent la limite de débit. Consultez « Streaming de journaux d’audit pour votre entreprise ».
Obtention d'une limite de débit plus élevée
Si vous souhaitez obtenir une limite de débit primaire plus élevée, présentez des requêtes authentifiées plutôt que des requêtes non authentifiées. Les requêtes authentifiées ont une limite de débit nettement plus élevée que les requêtes non authentifiées.
Si vous utilisez un personal access token pour l’automatisation dans votre organisation, déterminez si GitHub App fonctionnera à la place. GitHub Apps utilisées par les comptes GitHub Enterprise Cloud ont une limite de débit plus élevée que personal access tokens. Consultez « À propos de la création d’applications GitHub ».