Lever 429 "rate limit exceeded" during the agent's bulk candidate sync
Fixes Lever 429 rate limit exceeded during bulk candidate syncs. Use when parallel sync workers throttle the shared per-key limit and aggressive retries keep extending the penalty. Key trigger: cut concurrency first, then add exponential backoff with jitter.
TL;DR: Slow the sync down with backoff and jitter, and honor the Retry-After header when Lever sends one. The 429 means the agent is making calls faster than Lever allows per API key, and hammering retries without waiting just extends the throttle. Cut concurrency first, then add exponential backoff.
429 "rate limit exceeded"- Check the sync's concurrency: count how many parallel workers or threads are hitting the Lever API. Expected: you find the parallelism number (often far higher than needed).
- Drop concurrency to a small number (start with 2 to 4 parallel requests) and re-run the sync. Expected: the 429s stop or become rare.
- Add exponential backoff with jitter on 429: wait, double the wait on each consecutive 429, and add randomness so workers do not retry in lockstep. Expected: a throttled worker pauses instead of erroring out.
- Honor the Retry-After response header whenever Lever includes one: sleep exactly that long before the next call. Expected: the client waits the server-requested interval, not a guessed one.
- Cache slow-changing data (postings, stages, users) for the duration of the sync instead of re-fetching per candidate. Expected: total API calls per sync drop sharply and the sync finishes faster overall.
Use this when
- Lever returns 429 during bulk syncs, backfills, or parallel enrichment loops
- The 429s appear only under load and single requests succeed
- The agent retries aggressively and the throttle keeps extending
Not for this skill when
- The error is 401 or 403 (auth or permissions, not rate limiting)
- A single isolated request 429s (check whether the key is shared with another integration hammering the same limit)
- The sync needs to stay fast - consider whether the sync can be incremental instead of full
Variant phrasings
- Lever API throttling on bulk candidate sync
- Lever 429 too many requests from agent
- Lever API rate limit hit during sync
Why it happens
Lever caps how many API calls a key can make in a window. A bulk sync that fans out dozens of parallel workers - one per candidate, plus follow-up calls for notes, stages, and opportunities - blows through that cap in seconds. Each 429 without a proper wait keeps the client in the penalty box longer.
Edge cases
- Two integrations sharing one API key share one rate limit; the agent can 429 because of someone else's traffic. Give the agent its own key.
- Retrying a 429 immediately in a tight loop is the most common way a short throttle becomes a long one; always wait before retrying.
- If the sync is a daily full backfill, switch to incremental (only candidates changed since the last run) - fewer calls beats faster calls.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstCFa3RFLgfJ2Yibw2aYxxw