# Erros, retentativas e segurança operacional

Como desenhar integrações confiáveis com a API Zild sem duplicar conversas ou ignorar guardrails.

Source: https://zild.ai/pt-BR/docs/api-reference/errors-and-retries

## Status codes



<table class="api-params"><thead><tr><th>Status</th><th>Significado</th><th>Ação recomendada</th></tr></thead><tbody><tr><td><code>200</code></td><td>A requisição foi aceita ou concluída.</td><td>Persista IDs retornados quando existirem e continue o fluxo.</td></tr><tr><td><code>400</code></td><td>Payload, metadado ou arquivo obrigatório ausente ou inválido.</td><td>Corrija a requisição antes de tentar novamente.</td></tr><tr><td><code>401</code> / <code>403</code></td><td>Autenticação ausente, inválida, expirada ou sem permissão.</td><td>Atualize o token, rotacione a API key ou revise papéis e escopo.</td></tr><tr><td><code>404</code></td><td>A conversa solicitada não existe ou não está visível.</td><td>Confirme o ID numérico e o escopo autenticado.</td></tr><tr><td><code>429</code> / <code>5xx</code></td><td>A integração deve reduzir ritmo ou tentar depois.</td><td>Use backoff exponencial e alerte um operador se as falhas persistirem.</td></tr></tbody></table>



## 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.