429 indicates too many requests in a short period. Implement backoff and retries (pauses with jitter), distribute requests (avoid spikes), consume the scroll completely before it expires, and ensure there are no massive retries. For bulk operations, use prudent batching and avoid extreme concurrency.

Many APIs do not support wide multiget; for example, items/visits only accepts one product_id per query. If you need to reduce calls, design batching, use intervals, and limit RPM; for image diagnostics there is no official multiget, so limit the rate and only consider bulk requests if the endpoint supports it.

The main control is applied per Client ID (application) in most cases and per endpoint; payload size is not factored into the limit calculation. It is recommended to distribute application consumption and request quota increases for legitimate high-volume cases through the appropriate channels.

The scroll expires (limited time) and repeated consumption or leaving it open too long generates 429 (over quota). Consume the scroll pages within the validity window, reduce concurrency, and add backoff and retries with jitter to avoid spikes.

No. Using scroll_id together with offset/limit or incompatible parameters will cause errors. Use the appropriate pagination method for each endpoint and respect the chosen mechanism (scroll or offset).

For high-volume needs, contact the commercial integrations team with usage evidence; in the meantime, optimize calls (batching, consolidation by user_product) to reduce RPM and avoid blocks.