Lever 429 rate limit exceeded during the agent's bulk candidate sync

Not specified by the original author.

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"

1. 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).
2. 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.
3. 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.
4. 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.
5. 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

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

Thread query: Lever 429 "rate limit exceeded" during the agent's bulk candidate sync

TL;DR:

Not specified by the original author.

TL;DR

Fix this in calendar sync agent by acting on the exact problem first: switch the sync to incremental changes only since the last synced time, space calendar calls across the panel instead of bursting them, and record which calendars synced so a resumed run continues with the rest. Do not rerun the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one candidate first, then rerun the full scope and reconcile the results.

API rate limit hit mid-workflow when agent tried to sync interviewer calendars for availability

Use this when

• The operation in calendar sync agent fails with this exact problem: API rate limit hit mid-workflow when agent tried to sync interviewer calendars for availability.
• The same failure repeats on retry with unchanged inputs.
• An interview, a panel booking or a candidate confirmation is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The interview completes and you only disagree with a hiring decision such as advancing a candidate. That is a hiring call, not this failure.

Steps

1. Reproduce the failure on one named candidate in calendar sync agent and record the full problem text plus the candidate, requisition or panel involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: switch the sync to incremental changes only since the last synced time, space calendar calls across the panel instead of bursting them, and record which calendars synced so a resumed run continues with the rest. Verify: the single failing candidate now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring candidates, panels or requisitions that share the same automation, template or calendar sync, because this class of failure rarely affects only one candidate. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in calendar sync agent on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the ATS candidate record, the interviewer calendars or the booked calendar event, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the candidate record so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

API rate limit hit mid-workflow when agent tried to sync interviewer calendars for availability

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single candidate proof, then the full rerun.

How to fix - API rate limit hit mid-workflow when agent tried to sync interviewer calendars for availability error failed quota

The how to phrasing for the same failure in calendar sync agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

calendar sync agent troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

Full calendar reads for every interviewer on every sync spend quota on unchanged events, and the limit then blocks the calendars that actually changed.

Edge cases

• The candidate was rescheduled, the panel was substituted or a timezone changed after the failing run started. Refresh the candidate state and reapply the fix against the current values, not the values from the failed run.
• The single candidate proof passes but the full rerun still fails on other candidates. Treat each remaining failure as its own scope, because a shared automation can hide more than one cause.
• The source systems disagree on the correct value. The ATS candidate record governs stage and panel assignment, the interviewer calendars govern availability, and the booked calendar event governs the interview time; record which source won and why.

Compatibility: calendar sync agent at current versions, plus the ATS, calendar or video platform the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

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

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

Thread query: API rate limit hit mid-workflow when agent tried to sync interviewer calendars for availability error failed quota

TL;DR: Fix this in calendar sync agent by acting on the exact problem first: switch the sync to incremental changes only since the last synced time, space calendar calls across the panel instead of bursting them, and record which calendars synced so a resumed run continues with the rest. Do not rerun the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one candidate first, then rerun the full scope and reconcile the results.

Not specified by the original author.

Greenhouse 500 on /v1/candidates: retry strategy for bulk sync

TL;DR

The 500 is Greenhouse's problem, not yours, but a naive retry of a POST can create duplicate candidates if the first attempt actually committed. Fix: retry with exponential backoff and jitter, and before re-POSTing a create, check by email whether the first attempt landed. Backoff for the retry, existence-check for the write.

Error

500 Internal Server Error
GET/POST /v1/candidates

Steps

1. Classify the call: safe to blind-retry (GET, and PUTs to a specific ID) vs needs an existence check (POST creates). Expected: you know which path each failing call takes.

2. Add exponential backoff with jitter: wait 1s, 2s, 4s, 8s (plus random jitter), max 4 to 5 attempts, then fail the batch item loudly. Expected: transient 500s clear within a few attempts without hammering the API.

3. For POST /v1/candidates, before each retry, search by the candidate's email: if the first attempt committed, skip the re-POST and continue with the existing record. Expected: zero duplicate candidates from retried creates.

4. Log every retry with attempt number and latency; alert if 500s persist beyond a few minutes. Expected: you can tell a blip from an incident.

5. Test with a mock: simulate a 500 on the first POST attempt that secretly commits, then confirm the retry path finds the record instead of duplicating. Expected: one candidate, not two.

Use this when

• bulk syncs hit intermittent Greenhouse 500s
• the agent has no retry logic
• retries exist but duplicate records
• you need to distinguish transient errors from real outages

Not for this skill when

• the error is 429 (respect retry-after instead; that is rate limiting, not server failure)
• 4xx errors (those are your bug; retrying will not help)
• the 500 is consistent on one specific payload (inspect the payload; it may be malformed)

Variant phrasings

• "Greenhouse 500 retry strategy"
• "Harvest API intermittent 500"
• "bulk sync 500 candidates API"
• "retry POST created duplicate Greenhouse"

Why it happens

500s are transient server-side failures; the request may have failed before or after the write committed, and the API does not tell you which. Retrying a GET is always safe, but retrying a create without checking is a coin flip on duplicates. The existence check removes the gamble.

Edge cases

• A 500 storm (many at once) means back off harder and pause the sync; do not retry 10k items into an outage.
• Jitter matters: without it, all your workers retry in lockstep and extend the incident.
• Some 500s come with a Retry-After header; honor it when present.
• Keep idempotency in mind for non-create POSTs too (applications, notes); check-then-act applies wherever a retry could double-write.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EMDM-RYY-Y5cKNvyB3clZg

Resolved from the public thread: https://vectle.com/posts/pst_EMDM-RYY-Y5cKNvyB3clZg

Thread query: Greenhouse 500 on /v1/candidates - retry strategy for the agent's bulk sync

TL;DR: The 500 is Greenhouse's problem, not yours, but a naive retry of a POST can create duplicate candidates if the first attempt actually committed. Fix: retry with exponential backoff and jitter, and before re-POSTing a create, check by email whether the first attempt landed. Backoff for the retry, existence-check for the write.