API-Versionen

Informationen zur API-Versionsverwaltung

Die GitHub-REST-API ist versioniert. Der API-Versionsname basiert auf dem Datum, an dem die API-Version veröffentlicht wurde. Beispielsweise wurde die API-Version 2026-03-10 am Tue, 10 Mar 2026 veröffentlicht.

Breaking Changes sind Änderungen, die möglicherweise eine Integration unterbrechen können. Wir werden vorab benachrichtigt, bevor wir die Änderungen veröffentlichen. Zu Breaking Changes gehören:

• Entfernen eines gesamten Vorgangs
• Entfernen oder Umbenennen eines Parameters
• Entfernen oder Umbenennen eines Antwortfelds
• Hinzufügen eines neuen erforderlichen Parameters
• Erforderlichmachen eines zuvor optionalen Parameters
• Ändern des Typs eines Parameters oder Antwortfelds
• Entfernen von Enumerationswerten
• Hinzufügen einer neuen Validierungsregel zu einem vorhandenen Parameter
• Ändern der Authentifizierungs- oder Autorisierungsanforderungen

Alle additiven (Nonbreaking) Changes sind in allen unterstützten API-Versionen verfügbar. Additive Änderungen sind Änderungen, die eine Integration nicht unterbrechen sollten. Zu den additiven Änderungen gehören:

• Hinzufügen eines Vorgangs
• Hinzufügen eines optionalen Parameters
• Hinzufügen eines optionalen Anforderungsheaders
• Hinzufügen eines Antwortfelds
• Hinzufügen eines Antwortheaders
• Hinzufügen von Enumerationswerten

Wenn eine neue REST-API-Version veröffentlicht wird, wird die vorherige API-Version noch mindestens 24 Monate nach der Veröffentlichung der neuen API-Version unterstützt.

Angeben einer API-Version

Sie sollten den Header X-GitHub-Api-Version verwenden, um eine API-Version anzugeben. Beispiel:

curl --header "X-GitHub-Api-Version:2026-03-10" https://api.github.com/zen

Anforderungen ohne den Header X-GitHub-Api-Version verwenden standardmäßig die version 2022-11-28.

Wenn Sie eine API-Version angeben, die nicht mehr unterstützt wird, erhalten Sie eine 410 Gone Antwort.

Upgrade auf eine neue API-Version

Bevor du ein Upgrade auf eine neue REST-API-Version durchführst, solltest du das Änderungsprotokoll der Breaking Changes lesen, um zu verstehen, welche Breaking Changes enthalten sind und um weitere Informationen über das Upgrade auf diese bestimmte API-Version zu erhalten. Weitere Informationen finden Sie unter Aktuelle Änderungen.

Wenn Sie Ihre Integration aktualisieren, um die neue API-Version im Header X-GitHub-Api-Version anzugeben, müssen Sie auch alle änderungen vornehmen, die für Ihre Integration erforderlich sind, um mit der neuen API-Version zu arbeiten.

Sobald deine Integration aktualisiert ist, teste sie, um zu überprüfen, ob sie mit der neuen API-Version funktioniert.

API-Version Schließen

API-Versionen werden 24 Monate nach der Veröffentlichung einer neueren API-Version unterstützt.

Solange sich eine Version noch innerhalb ihres Supportzeitraums befindet, aber sich Schließen nähert, enthält GitHub die folgenden Header in den API-Antworten, um Sie bei der Vorbereitung der Migration zu unterstützen:

• Deprecation– Das Datum, an dem die API-Version als HTTP-Datum pro Schließen formatiert wird. Beispiel: Wed, 27 Nov 2019 14:34:29 GMT.
• Sunset — Das Datum, an dem die API-Version vollständig entfernt wird (Pensioniert), nach dem Anforderungen eine 410 Gone Antwort zurückgeben. Folgt RFC 8594. Beispiel: Fri, 27 Nov 2020 14:34:29 GMT.

Nach Beendigung des Supportfensters:

• Anforderungen, die eine Schließen API-Version angeben, erhalten eine 410 Gone Antwort.
• Anfragen, die keine API-Version angeben, verwenden standardmäßig die nächstältere unterstützte Version und nicht die Schließen Version. Wenn Sie sich auf nicht geversionte Anforderungen verlassen, können Sie Verhaltensänderungen beobachten, da ältere Versionen aus dem Support entfernt werden.

Weitere Informationen zum Migrieren zu einer neueren API-Version finden Sie unter Aktuelle Änderungen.

Ausnahmen von der Standardversionsverwaltung

In seltenen Fällen können GitHub Änderungen außerhalb des normalen API-Versionsverwaltungszyklus vorgenommen werden. Dies sind außergewöhnliche Interventionen, die die Standardversionsgarantien für die meisten Integratoren nicht ändern.

Sicherheits-, Verfügbarkeits- und Zuverlässigkeitsprobleme

Kritische Sicherheitsrisiken, Datengefährdungsrisiken oder schwerwiegende Zuverlässigkeitsprobleme erfordern möglicherweise Änderungen außerhalb des normalen Veröffentlichungszeitplans. GitHub kann eine ungeplante API-Version, Backportfixes für unterstützte Versionen oder in seltenen Fällen eine bahnbrechende Änderung an einer vorhandenen Version einführen, um Benutzer und Plattformintegrität zu schützen.

GitHub kommuniziert diese Änderungen über Versionshinweise, Änderungsprotokollen und direkte Kommunikation, die erläutert, was sich geändert hat und warum. Sofern möglich, wird eine Vorankündigung bereitgestellt. Sofortige Maßnahmen können bei Bedarf ohne vorherige Ankündigung ergriffen werden.

Dienste mit geringer Nutzung

Bei bestimmten Diensten mit sehr geringer Nutzung kann GitHub Funktionen außerhalb des Standard-Versionierungsprozesses als veraltet kennzeichnen. In diesen Fällen wird GitHub die Absicht mitteilen und sich direkt an die betroffenen Integratoren wenden.

Unterstützte API-Versionen

Die folgenden REST-API-Versionen werden derzeit unterstützt.

API-Version	Enddatum des Supports
2026-03-10	Not yet scheduled
2022-11-28	March 10, 2028

Du kannst auch eine API-Anforderung stellen, um alle unterstützten API-Versionen abzurufen. Weitere Informationen finden Sie unter REST-API-Endpunkte für Metadaten.