A maior parte da API compartilha um único envelope de resposta; alguns grupos
de endpoints encapsulam as respostas de forma diferente. Todos usam códigos
HTTP padrão — verifique-os primeiro.
Códigos de status
O 429 não é um limite geral da API. Ele só é retornado pelos endpoints
autenticados pelas formas securityToken (header), Bearer ou
userSecurityToken — na API pública, logo e recibos — após 30
tentativas de autenticação falhas do mesmo IP em uma hora. Os endpoints de
cartas, e-mail e WhatsApp fazem a própria autenticação e nunca respondem
429.
Envelopes
Padrão (cartas, e-mail, mensagens WhatsApp)
Modelos de WhatsApp / logo
Favoritos / verificação de número
Usado pelos endpoints de Cartas/Telegrama (v2), E-mail Registrado, Recibos
(erros) e pelos endpoints de mensagens e remetentes de WhatsApp. O
campo status espelha o código HTTP e o status_message traz o motivo
quando dá erro. Sucesso e erro trazem chaves diferentes — data só no sucesso,
message só no erro:Usado pelos endpoints de modelos de WhatsApp e pela sincronização de
modelos. O count aparece nos endpoints de listagem. O endpoint de logo do
remetente usa o mesmo formato sem request_id, e sempre inclui message
(vazio no sucesso). Contatos salvos e a verificação de número de WhatsApp retornam um objeto
simples { "success": ... }, sem envelope e sem id de requisição. O campo status / code do envelope sempre espelha o código HTTP real —
erros nunca são retornados dentro de um HTTP 200.
Id da requisição
Os endpoints que usam o envelope padrão devolvem também o header de resposta
X-Request-ID:
Cite esse valor ao relatar um problema — é a chave do log do servidor daquela
chamada exata. Os endpoints de modelos de WhatsApp devolvem o mesmo
identificador como request_id no corpo, em vez do header. Favoritos e a
verificação de número não devolvem nenhum dos dois. 
