Webhook do pedido
Normaliza payload, cria chave de idempotencia e rejeita evento incompleto antes de acionar o resto.
n8n em producao / logistica
Pedido, entrega e notificacao precisam ter rastro antes de automatizar volume.
Este demonstrativo mostra como eu organizaria um fluxo Angel Fly Command: entrada de pedido, validacao, upsert em banco, notificacoes WhatsApp/SMS, retry seguro e log para saber exatamente onde uma entrega falhou.
Postgres/MySQL
Upsert controlado em pedidos, entregas, motorista, status e historico sem duplicar corrida.
WhatsApp + SMS
UazAPI/Evolution e Twilio entram como canais transacionais, com fallback e estado por tentativa.
Erro auditavel
Execution log, motivo de falha, retry, replay manual e alerta quando a automacao deve parar.
debug que eu procuraria
Onde fluxos de entrega costumam quebrar
Webhook repetidoSem chave idempotente, o mesmo pedido pode virar duas entregas.
Race conditionStatus chega fora de ordem e sobrescreve etapa mais nova.
API sem retry claroTimeout vira silencio; ninguem sabe se notificou cliente ou motorista.
JSON instavelCampo muda de nome e quebra node Code/Function sem alerta legivel.
amostra sintetica
Fila de execucao
eventoestadoacao
order.createdokupsert + grupo
driver.assignedokSMS motorista
status.retryretry3 tentativas
payload.missingpararalertar humano
como eu documentaria
Entrega semanal sem virar caixa-preta
Para cada workflow: objetivo, gatilho, entrada esperada, credenciais/dependencias, tabela tocada, canais acionados, edge cases, como testar, como reprocessar e quando chamar humano.
limite seguro
O que fica fora do proof
Sem dados reais, sem contato externo, sem credenciais, sem envio real, sem promessa de uptime absoluto, sem bypass de WhatsApp/Twilio e sem mexer em billing/KYC/provedor.