Determine quando o estado influencia a decisão
Uma consulta feita na emissão pode ser suficiente para registrar aquele momento, mas não para afirmar indefinidamente o estado atual. Se a aplicação usa o documento numa nova decisão, defina se precisa consultar novamente. Essa escolha depende do processo e do risco, não apenas de otimização técnica. Guarde o momento da última conferência para que o usuário entenda a atualidade da informação exibida.
Diferencie estado conhecido e serviço indisponível
Quando a API não responde, o sistema pode conhecer apenas o resultado anterior. Mostre essa limitação em vez de exibir válido como se uma nova verificação tivesse ocorrido. Planeje mensagens e encaminhamento para o operador. A indisponibilidade também não deve ser convertida automaticamente em revogação: ausência de resposta e mudança de estado são situações distintas.
Escolha uma estratégia suportada
Alguns fornecedores oferecem notificações; outros exigem consulta periódica ou sob demanda. Confira o contrato atual antes de desenhar a arquitetura. Na Atestiva, use as operações documentadas de consulta e não presuma a existência de webhooks de saída para todo evento. Avalie limites, frequência, armazenamento do resultado e o que acontece quando várias aplicações consultam o mesmo registro.
Teste a mudança do estado no consumidor
Emita um registro fictício, consulte no sistema integrado e depois revogue-o com autorização. Verifique quando a aplicação reflete a mudança e se informa a data da conferência. Inclua uma falha de rede no teste. O aceite da integração deve estabelecer um comportamento observável para estado novo, resposta antiga e erro, evitando uma interface que transmite certeza maior do que a infraestrutura realmente possui.
Checklist para aplicar na sua operação
- Defina em quais decisões uma nova consulta é necessária.
- Mostre quando o último resultado foi obtido e quando não houve atualização.
- Teste revogação e indisponibilidade na aplicação consumidora, não só na API.