Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2026-04-23. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Versions des API

Découvrez comment spécifier la version d’API REST à utiliser chaque fois que vous faites une demande à l’API REST.

Dans cet article

À propos du contrôle de version de l’API

L’API GitHub REST 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 2026-03-10 de l’API a été publiée le Tue, 10 Mar 2026.

Les modifications disruptives sont des changements qui peuvent potentiellement interrompre une intégration. Les changements disruptifs seront publiés dans une nouvelle version d'une API. Nous fournirons un préavis avant de publier des changements cassants. Les modifications disruptives 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 410 Gone réponse.

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.

Version de l’API déconseillé

Les versions d’API sont prises en charge pendant 24 mois après la publication d’une version plus récente de l’API.

Bien qu’une version se trouve dans sa fenêtre de prise en charge, mais approche déconseillé, GitHub inclut les en-têtes suivants dans les réponses d’API pour vous aider à préparer la migration :

  • Deprecation — Date à laquelle la version de l’API sera déconseillémise en forme sous forme de date HTTP par RFC 7231. Par exemple : Wed, 27 Nov 2019 14:34:29 GMT.
  • Sunset — Date à laquelle la version de l’API sera complètement supprimée (mise hors service), après laquelle les demandes retourneront une 410 Gone réponse. Suit RFC 8594. Par exemple : Fri, 27 Nov 2020 14:34:29 GMT.

Une fois la fenêtre de support terminée :

  • Les demandes qui spécifient une version d’API déconseillé reçoivent une 410 Gone réponse.
  • Les demandes qui ne spécifient pas de version d’API utilisent par défaut la version la plus ancienne prise en charge, et non la version déconseillé. Si vous vous appuyez sur des demandes non modifiées, vous pouvez observer des modifications comportementales à mesure que les versions antérieures sont supprimées de la prise en charge.

Pour plus d’informations sur la migration vers une version plus récente de l’API, consultez Changements cassants.

Exceptions au contrôle de version standard

Dans de rares cas, GitHub des modifications peuvent être apportées en dehors de la cadence normale de contrôle de version de l’API. Il s’agit d’interventions exceptionnelles qui ne modifient pas les garanties de contrôle de version standard pour la plupart des intégrateurs.

Problèmes de sécurité, de disponibilité et de fiabilité

Les vulnérabilités de sécurité critiques, les risques d’exposition aux données ou les problèmes de fiabilité graves peuvent nécessiter des modifications en dehors de la planification normale des mises en production. GitHub peut publier une version d’API non planifiée, des correctifs rétroportés pour les versions prises en charge, ou dans de rares cas, introduire un changement disruptif dans une version existante afin de protéger les utilisateurs et l’intégrité de la plateforme.

          GitHub communiquera ces modifications par le biais des notes de publication, des journaux de modification et une communication directe expliquant ce qui a changé et pourquoi. Dans la mesure du possible, un avis préalable sera fourni. L’action immédiate peut être effectuée sans préavis préalable si nécessaire.

Services à faible utilisation

Pour certains services avec une utilisation très faible, GitHub peut déprécier les fonctionnalités en dehors du processus de contrôle de version standard. Dans ces cas, GitHub communiquera l’intention et contactera directement les intégrateurs concernés.

Versions d'API prises en charge

Les versions d’API REST suivantes sont actuellement prises en charge.

Version de l’APIDate de fin de support
2022-11-28March 10, 2028

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 ».