Pular para o conteúdo principal
A API responde com os status HTTP usuais: 2xx para sucesso, 4xx para um problema na requisição (chave, parâmetro, recurso, limite) e 5xx para uma falha do lado da Zouti. Todo erro com corpo JSON tem o mesmo formato:
string
Categoria do erro: authentication_error, permission_error, invalid_request_error, rate_limit_error ou api_error.
string
Motivo do erro, estável e em inglês. Trate os erros pelo code.
string
Explicação em português, para pessoas. Pode mudar a qualquer momento: não compare o texto.
string
Parâmetro que causou o erro (limit, cursor, status…). Só vem quando o erro é de um parâmetro; nos demais casos o campo não aparece.
string
Mesmo valor do header Request-Id. Informe-o ao suporte.

Códigos

invalid_request

400 · invalid_request_error Um parâmetro da requisição é inválido. param diz qual: limit fora de 1 a 100, data sem fuso, valor fora da lista em status, payment_method ou sort, ou um cursor alterado, de outra conta ou enviado com filtros ou sort diferentes dos da primeira página.
O que fazer: corrija o parâmetro indicado em param. Não repita a mesma requisição. Com param: "cursor", recomece a listagem sem cursor.
Uma requisição em HTTP (sem o S) também recebe 400, mas com corpo em texto puro (Use HTTPS: a API pública da Zouti não aceita HTTP.) e sem redirecionamento. Use sempre https:// e revogue a chave que já tenha sido enviada por HTTP.

invalid_api_key

401 · authentication_error A chave está ausente, malformada, não existe, foi revogada ou expirou. A resposta é a mesma em todos esses casos. A chave enviada na query string (?api_key=) também recebe 401.
O que fazer: confira o header Authorization: Bearer <chave> e envie a chave exatamente como foi copiada, sem espaço nem quebra de linha. Uma chave recém-criada pode levar cerca de 1 segundo para valer. Não repita em laço: 30 respostas 401 do mesmo IP em 60 segundos bloqueiam o IP com 429.

account_blocked

403 · permission_error A conta dona da chave está bloqueada.
O que fazer: fale com o suporte da Zouti. Repetir não muda a resposta.

insufficient_access

403 · permission_error A chave não tem o nível de acesso exigido pela rota.
O que fazer: use uma chave com acesso à operação. Repetir com a mesma chave não muda a resposta.

resource_missing

404 · invalid_request_error O recurso não existe, pertence a outra conta, ou a rota não existe. Um pedido de outra conta recebe a mesma resposta que um pedido inexistente.
O que fazer: confira o identificador (ord_...) e o caminho da rota. Não repita.

rate_limited

429 · rate_limit_error A conta passou do limite de requisições (rajada de 20 e reposição de 10 por segundo, somando todas as chaves), ou o IP passou do limite de falhas de autenticação (30 respostas 401 em 60 segundos). O header Retry-After diz quantos segundos esperar.
O que fazer: espere os segundos de Retry-After e repita. Se acontece com frequência, reduza as requisições em paralelo. Veja Limites de requisição.
429 sem corpo. Acima de 15.000 requisições em 5 minutos do mesmo IP, a borda responde 429 sem corpo JSON (sem error.code) e com Retry-After: 300. Trate o 429 pelo status HTTP, não pelo code.

internal_error

500 · api_error Erro inesperado na Zouti.
O que fazer: repita com espera crescente. Se persistir, informe o request_id ao suporte.

service_unavailable

503 · api_error Indisponibilidade temporária.
O que fazer: repita com espera crescente.

Autenticação antes da validação

A chave é conferida antes dos parâmetros. Uma requisição com chave errada e parâmetro inválido (por exemplo, limit=500) recebe 401 invalid_api_key, não 400. Corrija a chave primeiro.

Quando repetir

Repita automaticamente só 429, 500 e 503. Nunca repita 400, 401, 403 ou 404: a resposta não muda até a requisição mudar, e 401 repetido bloqueia o IP.
  1. Faça no máximo 5 tentativas no total (a primeira e mais 4).
  2. Se a resposta trouxer Retry-After, espere esses segundos.
  3. Senão, espere min(30, 0,5 × 2^n) segundos, com n = número de tentativas já feitas − 1, mais um jitter aleatório de 0 a 250 ms. Na prática: 0,5 s, 1 s, 2 s e 4 s, cada uma com o jitter.
  4. Depois da 5ª tentativa sem sucesso, desista e registre o erro com o Request-Id.
O jitter espalha as novas tentativas de vários processos no tempo, para não chegarem todas no mesmo instante. O código ao lado implementa essa regra.