Skip to main content

Formato de erro

Toda resposta de erro é um objeto plano — não há um sub-objeto details, os campos extras vêm soltos no mesmo nível de error e code:
Alguns erros trazem campos extras direto no corpo, conforme o caso:
  • error — texto pra exibição/log. Pode mudar de uma versão pra outra. Para cerca de 22 códigos ele repete o próprio code (como ERR_TOKEN_INVALID acima); para os demais é um texto legível em português (como ERR_RATE_LIMITED acima). Não dá pra prever qual caso é qual sem consultar o catálogo — por isso a regra abaixo.
  • code — identificador estável, sempre em maiúsculas com prefixo ERR_.
  • retryAfter, requiredScope, ticketId, param — extras que aparecem só em alguns códigos específicos (429, 403, 409 de flows, ERR_INVALID_DATE_FILTER).
Não faça match em error — nem para saber o tipo do erro, nem por igualdade de texto. Use sempre code: é o único campo estável entre versões.

Catálogo de códigos

Rate limit

Cada token pode fazer até 120 requisições por minuto. Toda resposta — inclusive as de erro — traz os headers:
  • X-RateLimit-Limit — limite por minuto (120).
  • X-RateLimit-Remaining — quantas ainda restam na janela atual.
  • X-RateLimit-Reset — epoch (segundos) de quando a janela reseta.
Ao exceder, a API responde 429 com code: ERR_RATE_LIMITED e o header Retry-After (segundos até poder tentar de novo).

Backoff em Node

Limite as tentativas (aqui, 3) em vez de retentar indefinidamente — se o 429 persistir depois disso, o problema provavelmente não é uma rajada passageira, e vale investigar o padrão de chamadas da sua integração antes de continuar insistindo.
Se sua integração faz muitas chamadas em rajada, prefira paginar com calma ou distribuir as chamadas no tempo em vez de confiar só no retry — o limite é por token, então rajadas grandes derrubam o Remaining rápido.