429 indica excesso de requisições em um curto período. Implemente backoff e retries (pausas com jitter), distribua as requisições (evite picos), consuma o scroll completamente antes de expirar e valide que não haja retries massivos. Para operações em massa, use batching prudente e evite concorrência extrema.

Muitas APIs não suportam multiget amplo; por exemplo, items/visits aceita apenas um product_id por consulta. Se for necessário reduzir chamadas, projete batching, use intervalos e limite o RPM; para diagnóstico de imagens não há multiget oficial, portanto limite o ritmo e considere requisições em massa somente se o endpoint suportar.

O controle principal é aplicado por Client ID (aplicação) na maioria dos casos e por endpoint; o tamanho do payload não é considerado no cálculo do limite. É recomendável distribuir o consumo da aplicação e solicitar aumento de cota em casos de volume legítimo pelos canais correspondentes.

O scroll expira (tempo limitado) e o consumo repetido ou deixado aberto por muito tempo gera 429 (sobre cota). Consuma as páginas do scroll dentro do tempo de validade, reduza a concorrência e adicione backoff e retries com jitter para evitar picos.

Não. Usar scroll_id junto com offset/limit ou parâmetros incompatíveis causará erros. Utilize o método de paginação adequado para cada endpoint e respeite o mecanismo escolhido (scroll ou offset).

Para necessidades de alto volume, entre em contato com a equipe de integrações comerciais com evidência de uso; enquanto isso, otimize chamadas (batching, consolidação por user_product) para reduzir RPM e evitar bloqueios.