429 indica exceso de peticiones en un corto período. Implementar backoff y retries (pausas con jitter), distribuir requests (evitar picos), consumir el scroll completamente antes de expirar y validar que no haya retries masivos. Para operaciones masivas use batching prudente y evite concurrencia extrema.

Muchas APIs no soportan multiget amplio; por ejemplo, items/visits acepta un solo product_id por consulta. Si es necesario reducir llamadas, diseñe batching, use intervalos y limite RPM; para diagnóstico de imágenes no hay un multiget oficial, por lo que debe limitarse el ritmo y considerar requests en masa solo si el endpoint lo soporta.

El control principal se aplica por Client ID (aplicación) en la mayoría de los casos y por pieza de endpoint; no se considera el tamaño del payload para cálculo del límite. Es recomendable distribuir el consumo de la app y solicitar aumento de cuota en casos de volumen legítimo mediante los canales correspondientes.

El scroll expira (tiempo limitado) y el consumo repetido o abierto por mucho tiempo genera 429 (sobre cuota). Consuma las páginas del scroll dentro del tiempo de vigencia, reduzca concurrencia, y añada backoff y retries con jitter para evitar picos.

No. Usar scroll_id junto con offset/limit o parámetros incompatibles causará errores. Utilice el método de paginación adecuado a cada endpoint y respete el mecanismo elegido (scroll o offset).

Para necesidades de alto volumen contacte al equipo de integraciones comerciales con evidencia de uso; mientras tanto, optimice llamadas (batching, consolidación por user_product) para reducir RPM y evitar bloqueos.