Changements potentiellement disruptifs et fin de vie (EoL) du Cato API

Cet article est une plateforme pour les notifications sur les changements potentiellement disruptifs et les annonces de fin de vie (EoL) du schéma Cato GraphQL API et contient des informations qui pourraient vous demander de mettre à jour le client API.

Les termes de l'API utilisées dans cet article sont expliqués dans Quoi est l'API Cato.

Pour tous les clients utilisant le Cato API, nous vous recommandons de cliquer sur Suivre pour recevoir automatiquement des notifications par email pour les mises à jour de cet article concernant les changements disruptifs de l'API. Vous pouvez également voir plus d'informations sur les nouvelles API et celles mises à jour dans le Journal des modifications de l'API de Cato.

Pour plus d'informations sur les API, voir la Référence de l'API GraphQL de Cato Networks.

Modifications potentiellement cassantes

2026-06-21 - Champs ID API: Modification de Type de Long/Entier à Chaîne

Actuellement, la passerelle API de Cato peut renvoyer les champs ID soit en tant que Chaîne, soit en tant que Long (entier). Dans le cadre d'une mise à jour prochaine de l'infrastructure, tous les champs ID seront systématiquement renvoyés en tant que Chaînes.

Ce qui change : Les réponses de l'API qui renvoyaient auparavant les champs ID en tant que valeurs numériques Long (par exemple, 1000000002), les renverront désormais toujours en tant que Chaînes (par exemple, "1000000002").
Qui est concerné : Les clients API qui traitent strictement les champs ID comme des types Long/entier peuvent rencontrer des problèmes lors du déploiement de cette modification.
Ce que vous devez faire avant le 21 juin 2026 : Mettre à jour le code de votre client API pour accepter à la fois les types Long et Chaîne pour les champs ID. Cela garantira une transition en douceur et évitera les perturbations lorsque la modification prendra effet.

2025-08-10 - Modification du champ Email dans les API addAdmin et updateAdmin

Le 10 août 2025, le champ email dans les API addAdmin et updateAdmin est devenu optionnel (nullable). Ce changement soutient la future infrastructure pour prendre en charge le contrôle d'accès API granulaire qui inclut des scripts et automatismes utilisant des principaux de service.

Les admins CMA humains actuels et futurs doivent toujours inclure une valeur email
Les requêtes qui retournent uniquement des admins humains ne sont pas affectées.
Certains clients peuvent avoir besoin de gérer les valeurs null dans les charges utiles de réponse, telles que addAdminPayload.

Ce n'est généralement pas un changement disruptif, mais cela peut avoir un impact sur les clients qui supposent que email est toujours présent. Passez en revue votre intégration pour éviter les problèmes.

2025-04-27 - API Query eventsFeed prend en charge la récupération des événements les plus récents

L'API eventsFeed utilise un marqueur pour permettre de tirer de manière itérative le flux d'événements. Le champ Marker affiche un identifiant qui indique le début d'une nouvelle itération pour récupérer des événements. L'API lit les événements de la file d'attente basée sur le champ Marker unique, et fournit le lieu du prochain marqueur dans la réponse. S'il n'y a pas de nouveaux événements dans la file d'attente, alors le champ Marker est vide

Un modèle alternatif de consommation d'événements est d'utiliser l'intégration directe sans code, voir Intégration des événements Cato avec AWS S3 et Intégration des événements Cato avec le compte de stockage Azure.

Qu'avons-nous changé ?

Auparavant, lorsque le marqueur n'était pas spécifié, l'API renvoyait le marqueur le plus ancien disponible. Cela nécessitait de consommer toute la file d'événements avant d'atteindre les événements les plus récents.
À partir du 27 avril 2025, si aucun marqueur n'est spécifié, l'API renvoie le marqueur le plus récent. Cela permet à l'API de récupérer directement les événements les plus récents.

Est-ce un changement disruptif ?

Il n'y a aucun impact pour la plupart des cas d'utilisation de l'API eventsFeed. Il n'y a aucun changement lorsque le champ Marqueur est utilisé pour une requête, et la logique de consommation du flux d'événements reste la même.
Si vous avez une logique dédiée pour consommer la file d'attente pour atteindre les événements récents, cette logique n'est plus nécessaire.
- Maintenant, si aucun marqueur d'entrée n'est spécifié, l'API fournit le marqueur le plus récent. Appeler l'API avec ce marqueur permet de récupérer les événements les plus récents.
- La réponse de l'API contient un marqueur qui pointe vers l'emplacement le plus récent (haut de la file d'attente)
- Les scripts correspondants et les processus automatisés doivent être mis à jour

2025-02-09 - Modification pour l'API XDR, limite=0 n'est plus prise en charge

Nous avons changé la fonctionnalité du champ limit de sorte que limit=0 n'est plus supporté car cela n'est pas considéré comme une bonne pratique. Pour assurer un fonctionnement fluide continu, vous devez mettre à jour tous les scripts ou requêtes qui dépendent de ce paramètre. Au lieu de cela, vous pouvez définir une limite entre 1-2000, que l'API prend entièrement en charge.

Si vous devez récupérer toutes les histoires, nous vous recommandons d'utiliser une approche de pagination.

Prochaines Annonces de Fin de Vie

Annonces de fin de vie précédentes

2026-03-18 - Fin de vie pour le champ SecondarySocketSerial

Le champ d'événement secondary_socket_serial dans l'API EventFieldName est actuellement marqué comme Déprécié et a atteint sa fin de vie (EoL) le 18 mars 2026.

Champ alternatif recommandé : socket_serial

2025-06-30 - Fin de vie pour les types LastMileBwInput, InterfaceInfo, et SocketInterfaceBandwidthInput

Les champs et types suivants dans l'API LastMileBWInput sont actuellement marqués comme Dépréciés et ont atteint leur fin de vie (EoL) le 30 juin 2025.