Apify rate limits
Handle Apify API rate limits with proper backoff and request queuing. Use when hitting 429 errors, optimizing API request throughput, or implementing rate-aware client wrappers. Trigger with "apify rate limit", "apify throttling", "apify 429", "apify retry", "apify backoff", "too many requests apify".From its SKILL.md
npx -y skills add jeremylongshore/claude-code-plugins-plus-skills --skill apify-rate-limitsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.2 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it
Apify Rate Limits
Overview
The Apify API enforces rate limits per resource. The apify-client library
auto-retries 429s (up to 8 times with exponential backoff), so most workloads never
notice a limit. You reach for this skill when bulk operations, custom API calls, or
large fan-outs push past what the built-in retry can absorb — you then batch, queue,
stagger, and monitor to stay under the ceiling.
Full runnable code for every step is in implementation.md; combined scenarios are in examples.md.
Apify rate limit rules
| Scope | Limit | Notes |
|---|---|---|
| Per resource (default) | 60 req/sec | Applies to each Actor, dataset, KV store independently |
| Dataset push | 60 req/sec per dataset | Batch items to reduce call count |
| Actor runs | 60 req/sec per Actor | Start runs in sequence or with delays |
| Platform-wide | Higher limit | Aggregate across all resources |
"Per resource" means: calls to dataset A and dataset B each get 60 req/sec
independently. Every response carries X-RateLimit-Limit,
X-RateLimit-Remaining, and X-RateLimit-Reset (epoch seconds) headers.
Prerequisites
- An Apify account with API access and
APIFY_TOKENset in the environment. - The
apify-clientpackage installed (npm install apify-client). - For custom queuing:
p-queue(npm install p-queue);crawleeforsleepand crawler-level concurrency.
Instructions
The workflow is five steps. Each is summarized here with its core lever; the full runnable code for every step is in implementation.md.
-
Understand built-in retries —
apify-clientalready retries 429/500+ with exponential backoff. TunemaxRetries/minDelayBetweenRetriesMillisonly when the defaults are wrong for your endpoint:import { ApifyClient } from 'apify-client'; const client = new ApifyClient({ token: process.env.APIFY_TOKEN, maxRetries: 5, // Default: 8 minDelayBetweenRetriesMillis: 500, // Default: 500 }); -
Batch operations (biggest lever) — collapse per-item loops into one batched call (up to 9 MB), chunking only for very large datasets:
await client.dataset(dsId).pushItems(items); // 1 call, not N -
Queue custom calls — gate raw API calls through
p-queue(concurrency+intervalCap) so fan-out reads never exceed 60 req/sec. See implementation.md § Step 3. -
Stagger Actor starts — insert a ~200 ms delay between
start()calls so the runs endpoint never 429s, thenwaitForFinish()in parallel. See implementation.md § Step 4. -
Monitor headers — feed
X-RateLimit-*into a small monitor that warns before the wall and pauses exactly until reset. See implementation.md § Step 5.
Target-website throttling is a separate ceiling from the platform API — cap it with
Crawlee's maxConcurrency / maxRequestsPerMinute
(implementation.md § Crawlee-level concurrency).
Output
Applying this skill produces a rate-aware Apify integration:
- A configured
ApifyClientwith an explicit retry envelope. - Batched/chunked dataset writes that cut API-call count by orders of magnitude.
- A
p-queue-gated call path that holds requests under 60 req/sec per resource. - Staggered Actor starts and, optionally, a header-driven monitor that pauses before exhaustion — the net effect being zero (or transparently retried) 429s under load.
Error Handling
| Scenario | Detection | Response |
|---|---|---|
| API 429 | apify-client auto-retries | Usually transparent; increase delays if persistent |
| Target site 429 | statusCode === 429 in handler | Reduce maxConcurrency, add proxy rotation |
| Burst of starts | Starting 100+ runs at once | Stagger with 200ms delays |
| Large data push | Single 50MB dataset push | Chunk into 9MB batches |
Examples
Worked end-to-end scenarios live in examples.md:
- Bulk dataset push without 429s — 50,000 rows in ~50 calls via chunked batching.
- Fan-out reads through a queue — 500 Actor reads held under 50 req/sec.
- Launch 100 runs safely — staggered starts, then parallel wait-for-finish.
- Pause on header-driven exhaustion — sleep exactly until the limit resets.
Resources
For security configuration, see apify-security-basics.
What ships with it: 2 files
7.3 KB alongside SKILL.md
references/
- examples.md2.3 KB
- implementation.md5.0 KB