apollo.io 429 rate limit exceeded

TL;DR

Back off with jittered exponential retries and cut concurrency; then check your Apollo plan's monthly credit and per-minute limits in the dashboard. Bulk enrichment jobs that fire in parallel are the classic trigger, and the fix is a paced queue, not faster retries.

apollo.io 429 rate limit exceeded

Use this when

• Apollo /v1/people/search or /v1/people/match returns 429
• An enrichment pipeline that worked yesterday starts 429ing today
• You need a retry wrapper for Apollo calls

Not for this skill when

• Apollo returns 401/403 (key invalid, or the endpoint is not on your plan)
• Enrichment returns 200 but with empty fields (data coverage, not rate limits)
• The 429 comes from a different API in the same pipeline

Steps

1. Check the Retry-After response header and honor it before any retry. Expected: you wait the server's stated window instead of guessing.
2. Add exponential backoff with jitter: 2s, 4s, 8s, up to 60s, max 5 attempts, and drop parallel workers on first 429. Expected: the burst drains and calls start succeeding.
3. Cap concurrency permanently: run enrichment at 1 to 3 concurrent requests (tune to your plan), never unbounded parallel loops. Expected: steady throughput with no 429s.
4. Open the Apollo usage dashboard and compare used credits and per-minute rates against your plan. Expected: you can distinguish a burst spike from genuine monthly-credit exhaustion.
5. If credits are exhausted, pause the job until reset or upgrade the plan; if only the per-minute rate tripped, the paced queue from step 3 is the fix. Expected: the job completes on the next scheduled run.

Variant phrasings

apollo people search 429

Same handling: honor Retry-After, then pace concurrency.

apollo.io api rate limit bulk enrichment

Bulk jobs need a queue with a per-minute cap; parallel map calls always trip this.

Tool/version compatibility

Apollo.io REST API v1 (api.apollo.io/v1). Rate behavior is plan-dependent; enterprise plans have higher per-minute ceilings but the same backoff discipline applies.

Why it happens

Apollo enforces both monthly credit quotas and per-minute request rate limits. A parallel enrichment loop can burn the per-minute budget in seconds even with credits remaining. Immediate retries amplify the burst, extending the throttled window, so the correct response is to slow down and serialize.

Edge cases / pitfalls

• /people/bulk_match counts each record against credits; one call can cost many credits, which 429s mask as rate limits.
• Cache enrichment results by domain or email to avoid re-burning credits on reruns.
• Do not rotate API keys or spin up extra accounts to dodge limits; that violates Apollo's terms.
• Read the key via os.environ.get("APOLLOAPIKEY") and never log it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_e0wjr4YRZbmMKBQB0IHcRw