Inblog
Loslegen

API-Versionierung und Deprecation

Erfahren Sie, wie Inblog API v1 unterstützt, künftige Deprecations ankündigt und das Ende des Supports plant.

Inblog versioniert die REST-API im URL-Pfad, damit Automatisierungen einen vorhersehbaren Vertrag verwenden können.

Aktuelle Unterstützung

v1 ist die derzeit unterstützte Version der REST-API. Verwenden Sie Endpunkte unter /api/v1/... und das OpenAPI-Dokument, um Integrationen zu erstellen.

Innerhalb von v1 bewahren wir für unterstützte Vorgänge die Rückwärtskompatibilität. Zusätzliche Antwortfelder und andere nicht inkompatible Verbesserungen können ohne eine neue URL-Version eingeführt werden. Für v1 wurde noch kein Deprecation- oder Sunset-Termin angekündigt.

Die API sendet derzeit nicht allein deshalb die Antwort-Header Deprecation oder Sunset für v1, weil diese Richtlinie existiert. Wenn die Header fehlen, wurde kein Signal zur Einstellung angekündigt.

Künftige Lebenszyklus-Signale

Wenn die Einstellung einer unterstützten API-Version geplant ist, kann Inblog diese Antwort-Header verwenden:

  • Deprecation zeigt an, dass die Version als veraltet markiert ist, und kann das Datum des Inkrafttretens enthalten.
  • Sunset zeigt das geplante Datum an, ab dem die Version nicht mehr unterstützt wird.

Diese Signale sind verschieden: Deprecation kündigt eine Änderung des Lebenszyklus an, während Sunset das geplante Ende des Supports bezeichnet. Wenn sie vorhanden sind, sollten Clients beide Header protokollieren und die verknüpfte Dokumentation oder Migrationsanleitung beachten.

Ankündigungsfrist

Unsere normale Richtlinie sieht mindestens 180 Tage Vorlauf vor, bevor v1 entfernt oder eine inkompatible Änderung an einer unterstützten API-Version vorgenommen wird. Dies ist ein vorsichtiges Minimum und keine Zusage, dass jede Änderung genau diesem Zeitplan folgt.

Eine Sicherheitslücke, eine gesetzliche Verpflichtung oder ein Notfall kann eine kürzere Frist oder eine sofortige Änderung erfordern. Unter solchen Bedingungen informieren wir so früh wie praktisch möglich über Auswirkungen und verfügbare Abhilfen.

Empfehlungen für Clients

  • Richten Sie Anfragen fest auf /api/v1 und leiten Sie die Version nicht aus Antwort-Headern ab.
  • Behandeln Sie hinzugefügte Felder als kompatibel und ignorieren Sie Felder, die Ihr Client nicht verwendet.
  • Überwachen Sie bei Migrationen die Header Deprecation und Sunset, die Release Notes und diese Richtlinie.
  • Verwenden Sie das OpenAPI-Dokument als maschinenlesbare Quelle des aktuellen Vertrags.

Zuletzt aktualisiert 2026-08-25

ZurückAPI- und MCP-AuthentifizierungWeiterPreise