O operador pede uma alteração de endereço e recebe “feito”. Horas depois, a entrega segue para o local antigo. A automação pode ter produzido uma resposta correta do ponto de vista da conversa, mas errado ao afirmar um efeito que ainda não havia sido confirmado pelo sistema responsável.
Para evitar essa diferença, a aplicação precisa separar intenção, tentativa e resultado. A pergunta decisiva é qual evidência autoriza cada mensagem ao usuário. O objetivo deste guia é tornar essa relação explícita, inclusive quando a integração demora, perde conexão ou devolve uma confirmação incompleta.
Uma resposta de rede não encerra o processo
Uma chamada pode chegar ao servidor e entrar numa fila. Também pode concluir a gravação e perder a resposta no caminho de volta. Esses casos exigem comportamentos diferentes: esperar pelo processamento no primeiro, consultar e reconciliar no segundo. Repetir a operação sem identificar o efeito anterior pode duplicar trabalho.
Especifique estados visíveis como recebido, aguardando processamento, confirmado, rejeitado e resultado desconhecido. Eles devem refletir o contrato real da integração. Se o fornecedor expõe apenas aceitação, a aplicação não deve converter esse sinal em confirmação de negócio por conveniência da interface.
O que o HTTP realmente informa
A RFC 9110 define 202 Accepted como aceitação para processamento ainda não concluído. O código, isoladamente, não demonstra que a alteração solicitada aconteceu.
A consequência de projeto é definir como acompanhar operações assíncronas: identificador de tarefa, consulta de estado, evento de conclusão ou reconciliação no sistema. Mesmo um código de sucesso precisa ser interpretado conforme o contrato do endpoint e o efeito específico que se pretende comprovar.
Exemplo composto: mudança de endereço em espera
Uma empresa fictícia recebe o pedido de alteração antes da expedição. A ferramenta valida o novo endereço e devolve um protocolo de processamento. A resposta adequada informa que a solicitação foi recebida e ainda depende de confirmação, sem prometer que a transportadora já usará o novo destino.
Na consulta seguinte, o ERP mostra a alteração gravada, mas o TMS ainda não a incorporou. O fluxo apresenta essa pendência e o responsável pela exceção. Somente após a confirmação relevante para a entrega o atendimento comunica a conclusão. O exemplo não pressupõe que toda integração ofereça os mesmos estados.
Construa uma cadeia de comprovação
Defina o efeito mínimo esperado: registro criado, campo atualizado ou evento aceito pela etapa seguinte. Guarde o identificador devolvido e associe-o à solicitação original. Se o dado pode ser alterado por outras pessoas, registre também a versão observada e o horário da confirmação.
Estabeleça um prazo para resolver estados desconhecidos. Após um timeout, tente consultar a operação antes de reenviar. Se não houver forma segura de saber o resultado, encaminhe para reconciliação humana com as tentativas já realizadas. A experiência deve permitir acompanhar o protocolo sem repetir todo o comando.
Checklist de mensagens que correspondem a fatos
- Documente qual evidência permite afirmar cada estado.
- Teste sucesso síncrono, aceitação assíncrona e resposta perdida.
- Associe novas tentativas à mesma operação de negócio.
- Defina prazo e responsável para resultados desconhecidos.
- Meça falsas confirmações e tempo até confirmação verificável.
Revise amostras de conversas junto com o registro final no sistema. Contar respostas positivas do agente superestima o sucesso quando ainda existe trabalho pendente. Separe falha de execução, atraso e erro de comunicação: cada categoria pede uma correção diferente e merece aparecer na análise do piloto.
Como a Uiless ajuda
Ferramentas por contrato, evidência e idempotência dão à Uiless uma base para relacionar solicitação e execução. O desenho de cada conector determina como o resultado será verificado. Um sistema que não disponibiliza confirmação exige um caminho explícito de consulta ou reconciliação, sem promessa de conclusão automática.
O tema aprofunda por que a automação precisa deixar evidência e complementa webhooks, idempotência e novas tentativas. Comece revisando os verbos que a interface usa para comunicar sucesso.
