Formato de erro
Toda resposta de erro é um objeto plano — não há um sub-objetodetails, os campos extras vêm soltos no mesmo nível de error e code:
error— texto pra exibição/log. Pode mudar de uma versão pra outra. Para cerca de 22 códigos ele repete o própriocode(comoERR_TOKEN_INVALIDacima); para os demais é um texto legível em português (comoERR_RATE_LIMITEDacima). 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 prefixoERR_.retryAfter,requiredScope,ticketId,param— extras que aparecem só em alguns códigos específicos (429, 403, 409 de flows,ERR_INVALID_DATE_FILTER).
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.
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.