Cambios Potencialmente Críticos y EoL del Cato API

Desde el 30 de agosto de 2026, estamos aplicando validaciones de tipo más estrictas en toda la API para alinearse con el esquema documentado. Las llamadas API que pasan un Valor en un Formato que no coincide con el Tipo documentado del campo podrían verse afectadas, dependiendo del Punto de conexión.

• Qué está cambiando: Los parámetros deben coincidir exactamente con su Tipo definido por el esquema. Por ejemplo, los Campos Int solo aceptarán valores enteros — las entradas de cadena como "5" ya no serán aceptadas. Esto no se limita a los Campos Int — cualquier parámetro pasado en un Formato que no coincida con su Tipo documentado podría verse afectado.

• Qué deberías hacer antes del 30 de agosto de 2026:

  • Revisa tus llamadas API para Valores pasados en un Formato que no coincide con el Tipo de esquema documentado (por ejemplo, valores numéricos pasados como cadenas).

  • Actualiza cualquier llamada desalineada.

Actualmente, la puerta de enlace API de Cato puede devolver los campos ID como Cadena o Long (entero). Como parte de una próxima actualización de la infraestructura, todos los campos de ID se devolverán consistentemente como Cadenas.

• Qué está cambiando: Las respuestas de la API que anteriormente devolvían campos de ID como valores numéricos Long (por ejemplo, 1000000002) ahora siempre los devolverán como Cadenas (por ejemplo, "1000000002").

• Quién está afectado: Los clientes de API que manejan campos ID estrictamente como tipos Long/entero pueden presentar problemas cuando este cambio se implemente.

• Qué debe hacer antes del 21 de junio de 2026: Actualice el código del cliente API para aceptar tanto tipos Long como Cadena para los campos de ID. Esto garantizará una transición sin problemas y evitará interrupciones cuando el cambio tenga efecto.

El 10 de agosto de 2025, el campo correo electrónico en las API de addAdmin y updateAdmin se volvió opcional (admite valor nulo). Este cambio apoya la infraestructura entrante para soportar un control de acceso API granular que incluye scripts y automatizaciones utilizando entidades de servicio.

• Los administradores humanos CMA actuales y futuros deben siempre incluir un valor de correo electrónico

• Las consultas que devuelven solo administradores humanos no se ven afectadas.

• Algunos clientes pueden necesitar manejar valores nulos en las cargas de respuesta, como addAdminPayload

Esto típicamente no es un cambio crítico, pero puede impactar a los clientes que asumen que email siempre está presente. Revisa tu integración para evitar problemas.

La API eventsFeed utiliza un marcador para permitir el acceso iterativo al feed de eventos. El campo Marker muestra un identificador que indica el inicio de una nueva iteración para obtener eventos. La API lee eventos de la cola basada en el campo Marker único y proporciona la siguiente ubicación del marcador en la respuesta. Si no hay nuevos eventos en la cola, entonces el campo Marker está vacío

Un modelo alternativo de consumo de eventos es usar la integración directa sin código, vea Integrando eventos de Cato con AWS S3 y Integrando eventos de Cato con Cuenta de Almacenamiento de Azure.

¿Qué hemos cambiado?

• Previamente, cuando el marcador no estaba especificado, el API devolvía el marcador más antiguo disponible. Esto requería consumir toda la cola de eventos antes de alcanzar los eventos más recientes.

• A partir del 27 de abril de 2025, si no se especifica un marcador, el API devuelve el marcador más reciente. Esto permite que el API recupere los eventos más recientes directamente.

¿Es un cambio crítico?

• No hay impacto para la mayoría de los casos de uso del API eventsFeed. No hay cambios cuando se utiliza el campo Marker para una consulta, y la lógica de consumo del feed de eventos es la misma.

• Si tienes una lógica dedicada para consumir la cola de eventos recientes, ya no es necesaria.

  • Ahora, si no se especifica un marcador de entrada, el API proporciona el marcador más reciente. Llamando al API con este marcador se obtienen los eventos más recientes.

  • La respuesta del API contiene un marcador que apunta a la ubicación más reciente (parte superior de la cola)

  • Los correspondientes guiones y procesos automatizados deben ser actualizados

Hemos cambiado la funcionalidad del campo limit para que limit=0 ya no sea soportado porque no se considera una buena práctica. Para asegurar el funcionamiento continuo sin problemas, debes actualizar cualquier script o consulta que dependa de este parámetro. En su lugar, puedes establecer un límite entre 1-2000, que la API soporta completamente.

Si necesitas recuperar todas las historias, recomendamos utilizar un enfoque de paginación.

El campo de evento secondary_socket_serial en la API EventFieldName está actualmente marcado como Obsoleto y llegó al fin de su vida (EoL) el 18 de marzo de 2026.

Campo alternativo recomendado: socket_serial

Los siguientes campos y tipos en la API LastMileBWInput están actualmente marcados como Obsoletos y llegaron al fin de su vida (EoL) el 30 de junio de 2025.

Por favor, use los campos y tipos recomendados en su lugar.

Los siguientes campos y tipos en la API InterfaceInfo están actualmente marcados como Obsoletos y llegaron al fin de su vida (EoL) el 30 de junio de 2025.

Por favor, use los campos y tipos recomendados en su lugar.

Los siguientes campos y tipos en la API SocketInterfaceBandwidthInput están actualmente marcados como Obsoletos y llegaron al fin de su vida (EoL) el 30 de junio de 2025.

Por favor, use los campos y tipos recomendados en su lugar.

• La API de consulta auditFeed acepta una lista de filtros usando el tipo AuditFieldFilterInput. Cada filtro incluye un fieldName definido por el tipo FieldNameInput, que actualmente incluye dos campos de entrada: AuditFieldName y EventFieldName.

• Sin embargo, solo AuditFieldName es un campo de entrada válido y soportado. Para mejorar la claridad del esquema y evitar confusiones, el campo EventFieldName fue eliminado del esquema el 8 de junio de 2025.

• Actualiza todos los scripts y consultas que utilicen filtros auditFeed para usar solamente el campo de entrada AuditFieldName.

Los siguientes campos y tipos en la API EventFieldName están actualmente marcados como Obsoletos y llegaron al fin de su vida (EoL) el 1 de mayo de 2025.

Por favor, use los campos y tipos recomendados en su lugar.

El campo bgp_peer_description en la API EventFieldName fue marcado como Obsoleto y está fuera de servicio (EoL) desde el 15 de abril de 2025.

Los siguientes campos y tipos en la API EventFieldName fueron marcados como Obsoletos y están en fin de vida útil (EoL) desde el 1 de marzo de 2025.

Por favor, use los campos y tipos recomendados en su lugar.

El siguiente campo en la API Beta StoryDrillDownFilter fue marcado como Obsoleto y está en fin de vida útil (EoL) desde el 23 de febrero de 2025.

Por favor, use los campos y tipos recomendados en su lugar.

Siguiendo el anuncio de EoL para algunos valores de SubTipo usados en las APIs de consumo de eventos relacionadas con los Clientes de Cato, el despliegue está pausado para las cuentas que usan la ubicación CMA de Irlanda (cc.catonetworks.com) para los siguientes campos:

• Para más información, consulte CMA - Directrices Técnicas

Los siguientes campos y tipos relacionados con el Cliente Cato fueron marcados como obsoletos y alcanzarán el fin de vida (EoL) el 2 de enero de 2025.

Por favor, use los campos y tipos recomendados en su lugar.

• Para más información, consulte este artículo: Próximo Fin de Vida Útil para Algunos SubTipos de Datos de Evento de Cato