Versionnement et dépréciation de l’API

Découvrez comment Inblog prend en charge l’API v1, annonce les futures dépréciations et planifie la fin du support.

Inblog versionne son API REST dans le chemin de l’URL afin que les automatisations puissent utiliser un contrat prévisible.

Support actuel

v1 est la version actuellement prise en charge de l’API REST. Utilisez les endpoints sous /api/v1/... et le document OpenAPI pour créer vos intégrations.

Nous préservons la compatibilité descendante au sein de v1 pour les opérations prises en charge. Des champs de réponse supplémentaires et d’autres améliorations non incompatibles peuvent être ajoutés sans créer une nouvelle version d’URL. Aucune date de dépréciation ou de fin de support de v1 n’a été annoncée.

L’API n’envoie actuellement pas les en-têtes de réponse Deprecation ou Sunset pour v1 simplement parce que cette politique existe. Leur absence signifie qu’aucun signal de retrait n’a été annoncé.

Signaux futurs du cycle de vie

Si le retrait d’une version prise en charge est planifié, Inblog peut utiliser les en-têtes de réponse suivants :

• Deprecation indique que la version est dépréciée et peut inclure la date de prise d’effet de la dépréciation.
• Sunset indique la date prévue après laquelle la version ne sera plus prise en charge.

Ces signaux sont distincts : la dépréciation annonce un changement de cycle de vie, tandis que Sunset identifie la fin de support prévue. Lorsqu’ils sont présents, enregistrez les deux en-têtes et consultez la documentation ou le guide de migration associé.

Délai de préavis

Notre politique habituelle prévoit un préavis minimum de 180 jours avant de supprimer v1 ou d’introduire une modification incompatible dans une version d’API prise en charge. Il s’agit d’un minimum prudent, et non d’une promesse que chaque changement suivra exactement ce calendrier.

Une faille de sécurité, une obligation légale ou une situation d’urgence peut nécessiter un préavis plus court ou une modification immédiate. Dans ces conditions, nous communiquerons l’impact et les mesures correctives disponibles dès que possible.

Conseils pour les clients

• Fixez les requêtes sur /api/v1 au lieu de déduire la version des en-têtes de réponse.
• Traitez les champs ajoutés comme compatibles et ignorez ceux que votre client n’utilise pas.
• Surveillez les en-têtes Deprecation et Sunset, les notes de version et cette politique lors de la préparation d’une migration.
• Utilisez le document OpenAPI comme source lisible par machine du contrat actuel.

Liens associés

• Document OpenAPI
• Manifeste du serveur MCP
• Authentification API et MCP

Dernière mise à jour 2026-08-25