Rate Limiting

Rate limiting restricts how frequently a client may act — for example 60 requests per minute per IP or per account. Servers use it to stay stable under load and to blunt scraping and brute-force attempts. When you exceed a limit you typically receive an HTTP 429 "Too Many Requests" response, sometimes with a Retry-After header telling you how long to wait. Limits may be keyed on your IP address, an API key, an account or a combination, so the boundary you hit depends on how the service counts you.

Because many limits are per-IP, distributing requests across addresses is a common way to raise aggregate throughput without exceeding any single limit — one role of a proxy pool in web scraping. The ethical approach is to respect published limits, back off on a 429 rather than retrying instantly, and add jitter between requests so your pattern looks less mechanical. s4m itself can tune usage limits across account-type, per-IP and per-account axes. Design your client to slow down gracefully; hammering through a 429 usually earns a longer block, not faster data.

s4m itself can tune usage limits across account-type, per-IP and per-account axes, so limits appear on both sides of a connection. In your own clients, design for graceful slow-down: honour Retry-After, add jitter between requests, and spread load across a proxy pool when a target counts by IP. Hammering through a 429 usually earns a longer block, not faster data, so back off, and prefer an official API when a site offers one.