Erros, retentativas e segurança operacional
Como desenhar integrações confiáveis com a API Zild sem duplicar conversas ou ignorar guardrails.
Status codes
| Status | Significado | Ação recomendada |
|---|---|---|
200 | A requisição foi aceita ou concluída. | Persista IDs retornados quando existirem e continue o fluxo. |
400 | Payload, metadado ou arquivo obrigatório ausente ou inválido. | Corrija a requisição antes de tentar novamente. |
401 / 403 | Autenticação ausente, inválida, expirada ou sem permissão. | Atualize o token, rotacione a API key ou revise papéis e escopo. |
404 | A conversa solicitada não existe ou não está visível. | Confirme o ID numérico e o escopo autenticado. |
429 / 5xx | A integração deve reduzir ritmo ou tentar depois. | Use backoff exponencial e alerte um operador se as falhas persistirem. |
Desenho de retentativas
Desenhe clientes para que uma retentativa de rede não crie contato duplicado. Para conversas proativas, mantenha seu próprio ID de campanha/item e não tente novamente cegamente após resultado desconhecido.
Logs
Registre endpoint, timestamp, identificador de workspace, ID de origem e ID da conversa Zild. Não registre API keys, bearer tokens, segredos de clientes ou transcrições completas sem política de retenção.
Guardrails de revisão humana
Quando uma requisição puder disparar ação visível ao cliente, prefira templates, filas e usuários configurados a automações ad hoc. Se o sistema de origem não tem contexto suficiente, crie ou roteie a conversa com metadados corretos e deixe a plataforma escalar.