À propos du contrôle de version de l’API
L'API REST GitHub REST API est versionnée. Le nom de la version de l’API est basé sur la date à laquelle la version de l’API a été publiée. Par exemple, la version de l’API 2026-03-10 a été publiée sur Tue, 10 Mar 2026.
Les changements cassants sont des modifications qui peuvent potentiellement arrêter une intégration. Nous fournirons un préavis avant de publier des changements cassants. Les changements cassants incluent :
- Suppression d’une opération entière
- Suppression ou changement de nom d’un paramètre
- Suppression ou changement de nom d’un champ de réponse
- Ajout d’un nouveau paramètre obligatoire
- Rendre obligatoire un paramètre précédemment facultatif
- Modification du type d’un paramètre ou d’un champ de réponse
- Suppression des valeurs d’énumération
- Ajout d’une nouvelle règle de validation à un paramètre existant
- Modification des exigences d’authentification ou d’autorisation
Tous les changements additifs (non cassants) seront disponibles dans toutes les versions d’API prises en charge. Les changements additifs sont des modifications qui ne doivent pas interrompre une intégration. Les changements additifs sont les suivants :
- Ajout d’une opération
- Ajout d’un paramètre facultatif
- Ajout d’un en-tête de demande facultatif
- Ajout d’un champ de réponse
- Ajout d’un en-tête de réponse
- Ajout de valeurs d’énumération
Lorsqu’une nouvelle version d’API REST est publiée, la version précédente de l’API est prise en charge pendant au moins 24 mois supplémentaires après la publication de la nouvelle version de l’API.
À propos du versionnage GitHub Enterprise Server et du versionnage d’API REST
Les versions GitHub Enterprise Server sont découplées des versions de l’API REST. Vous pouvez mettre à niveau votre GitHub Enterprise Server version, mais conserver la même version de l’API REST tant que la version de l’API est incluse dans la GitHub Enterprise Server version. De même, vous pouvez mettre à niveau votre version de l’API REST sans mettre à jour votre GitHub Enterprise Server version, tant que la nouvelle version de l’API REST que vous choisissez est disponible pour votre GitHub Enterprise Server version.
Les GitHub Enterprise Server notes de publication indiquent quand une version de l’API REST n’est plus prise en charge. Pour plus d’informations, consultez « Notes de publication ».
Spécification d’une version d’API
Vous devez utiliser l’en-tête X-GitHub-Api-Version pour spécifier une version d’API. Par exemple :
curl --header "X-GitHub-Api-Version:2022-11-28" https://api.github.com/zen
Les requêtes sans l’en-tête X-GitHub-Api-Version utilisent par défaut la version 2022-11-28.
Si vous spécifiez une version d’API qui n’est plus prise en charge, vous recevrez une erreur 400.
Mise à niveau vers une nouvelle version de l’API
Avant de procéder à la mise à niveau vers une nouvelle version d’API REST, vous devez lire le journal de modifications des ruptures de compatibilité qui correspond à la nouvelle version de l’API pour comprendre les modifications critiques incluses et obtenir plus d'informations sur la mise à niveau vers cette version spécifique de l’API. Pour plus d’informations, consultez « Changements cassants ».
Lorsque vous mettez à jour votre intégration pour spécifier la nouvelle version de l'API dans l'en-tête X-GitHub-Api-Version, vous devez également apporter des modifications requises pour que votre intégration fonctionne avec la nouvelle version de l'API.
Une fois votre intégration mise à jour, testez votre intégration pour vérifier qu’elle fonctionne avec la nouvelle version de l’API.
Versions d'API prises en charge
Les versions d’API REST suivantes sont actuellement prises en charge :
2022-11-28
Vous pouvez également faire en sorte qu’une demande d’API obtienne toutes les versions d’API prises en charge. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les métadonnées ».