Possíveis Alterações Incompatíveis na API Cato e EoL

A partir de 30 de agosto de 2026, estamos implementando uma validação de tipo mais estrita em toda a API para alinhar com o esquema documentado. Chamadas de API que passam um valor em um formato que não corresponde ao tipo documentado do campo podem ser afetadas, dependendo do ponto de extremidade.

• O que está mudando: Os parâmetros devem corresponder exatamente ao tipo definido no esquema. Por exemplo, campos do tipo Int aceitarão apenas valores inteiros — entradas de string como "5" não serão mais aceitas. Isso não se limita a campos Int — qualquer parâmetro passado em um formato que não corresponda ao tipo documentado pode ser afetado.

• O que você deve fazer antes de 30 de agosto de 2026:

  • Revise suas chamadas de API para valores passados em um formato que não corresponda ao tipo de esquema documentado (por exemplo, valores numéricos passados como strings).

  • Atualize qualquer chamada desalinhada.

Atualmente, o gateway da API da Cato pode retornar campos de ID como String ou Long (inteiro). Como parte de uma próxima atualização de infraestrutura, todos os campos de ID serão consistentemente retornados como Strings.

• O que está mudando: As respostas da API que anteriormente retornavam campos de ID como valores numéricos Long (por exemplo, 1000000002) agora sempre os retornam como Strings (por exemplo, "1000000002").

• Quem é afetado: Clientes de API que manipulam campos de ID estritamente como tipos Long/inteiro podem apresentar falhas quando essa mudança for implementada.

• O que você deve fazer antes de 21 de junho de 2026: Atualize o código do seu cliente de API para aceitar tanto Longs quanto Strings para os campos de ID. Isso garantirá uma transição suave e evitará interrupções quando a alteração entrar em vigor.

Em 10 de agosto de 2025, o campo email nas APIs addAdmin e updateAdmin tornou-se opcional (pode ser nulo). Essa alteração suporta infraestrutura futura para controle de acesso granular à API que inclui scripts e automações usando principais de serviço.

• Administradores humanos CMA atuais e futuros devem sempre incluir um valor email

• Consultas que retornam apenas administradores humanos não são afetadas.

• Alguns clientes podem precisar lidar com valores nulos em payloads de resposta, como addAdminPayload

Isso não é tipicamente uma alteração incompatível, mas pode impactar clientes que assumem que o email sempre está presente. Revise sua integração para evitar problemas.

A API eventsFeed usa um marcador para permitir puxar iterativamente o feed de eventos. O campo Marker mostra um identificador que indica o início de uma nova iteração para buscar eventos. A API lê eventos da fila com base no campo Marker único, e fornece a próxima localização do marcador na resposta. Se não houver novos eventos na fila, então o campo Marker fica vazio

Um modelo alternativo de consumo de eventos é usar a integração direta sem código, veja Integração de Eventos Cato com AWS S3 e Integração de Eventos Cato com Conta de Armazenamento Azure.

O que mudamos?

• Anteriormente, quando o marcador não era especificado, a API retornava o marcador mais antigo disponível. Isso exigia consumir toda a fila de eventos antes de alcançar os eventos mais recentes.

• A partir de 27 de abril de 2025, se nenhum marcador for especificado, a API retorna o marcador mais recente. Isso permite que a API busque diretamente os eventos mais recentes.

É uma alteração incompatível?

• Não há impacto para a maioria dos casos de uso da API eventsFeed. Não há mudança quando o campo Marker é usado para uma consulta, e a lógica de consumo de eventos permanece a mesma.

• Se você tiver uma lógica dedicada para consumir a fila até alcançar os eventos recentes, essa lógica não é mais necessária.

  • Agora, se nenhum marcador de entrada for especificado, a API fornece o marcador mais recente. Chamar a API com este marcador busca os eventos mais recentes

  • A resposta da API contém um marcador que aponta para a localização mais recente (topo da fila)

  • Os scripts correspondentes e os processos automatizados devem ser atualizados

Alteramos a funcionalidade do campo limit para que limit=0 não seja mais suportado, já que isso não é considerado uma boa prática. Para garantir a continuidade do funcionamento suave, você precisa atualizar quaisquer scripts ou consultas que dependam desse parâmetro. Em vez disso, você pode definir um limite entre 1-2000, que é totalmente suportado pela API.

Se você precisar recuperar todas as histórias, recomendamos usar uma abordagem de paginação.

O campo de evento secondary_socket_serial na API EventFieldName está atualmente marcado como Obsoleto e atingiu o fim de vida (EoL) em 18 de março de 2026.

Campo alternativo recomendado: socket_serial

Os seguintes campos e tipos na API LastMileBWInput estão atualmente marcados como Obsoletos e atingiram o fim de vida (EoL) em 30 de junho de 2025.

Por favor, use os campos e tipos recomendados em vez disso.

Os seguintes campos e tipos na API InterfaceInfo estão atualmente marcados como Obsoletos e atingiram o fim de vida (EoL) em 30 de junho de 2025.

Por favor, use os campos e tipos recomendados.

Os seguintes campos e tipos na API SocketInterfaceBandwidthInput estão atualmente marcados como Obsoletos e atingiram o fim de vida (EoL) em 30 de junho de 2025.

Por favor, use os campos e tipos recomendados em vez disso.

• A API de consulta auditFeed aceita uma lista de filtros usando o tipo AuditFieldFilterInput. Cada filtro inclui um fieldName definido pelo tipo FieldNameInput, que atualmente inclui dois campos de entrada: AuditFieldName e EventFieldName.

• No entanto, apenas AuditFieldName é um campo de entrada válido e suportado. Para melhorar a clareza do esquema e evitar confusões, o campo EventFieldName foi removido do esquema em 8 de junho de 2025.

• Atualize todos os scripts e consultas que usam filtros auditFeed para usar apenas o campo de entrada AuditFieldName.

Os seguintes campos e tipos na API EventFieldName estão atualmente marcados como Obsoletos e atingiram o fim de vida (EoL) em 1 de maio de 2025.

Por favor, use os campos e tipos recomendados em vez disso.

O campo bgp_peer_description na API EventFieldName foi marcado como Obsoleto e está no final de sua vida útil (EoL) a partir de 15 de abril de 2025.

Os campos e tipos seguintes na API EventFieldName foram marcados como Obsoletos e estão no fim de vida (EoL) a partir de 1 de março de 2025.

Por favor, use os campos e tipos recomendados.

O campo seguinte na API Beta StoryDrillDownFilter foi marcado como Obsoleto e está no fim de vida (EoL) a partir de 23 de fevereiro de 2025.

Por favor, use os campos e tipos recomendados em vez disso.

Após o anúncio de EoL para alguns valores de SubType usados nas APIs de consumo de eventos relacionados aos Clientes Cato, a implementação está pausada para contas que usam a localização CMA Irlanda (cc.catonetworks.com) para os seguintes campos:

• Para mais informações, consulte CMA - Diretrizes Técnicas

Os seguintes campos e tipos relacionados ao Cliente Cato foram marcados como Obsoletos e estão em fim de vida (EoL) a partir de 2 de janeiro de 2025.

Por favor, use os campos e tipos recomendados.

• Para mais informações, veja este artigo: Próximo EoL para Alguns SubTypes dos Dados de Eventos Cato