TL;DR: Read the Retry-After header on every 429 and sleep that long before retrying, instead of retrying on a fixed guess. This 429 variant tells you exactly how long to wait - 60 seconds - and an agent that ignores the header either retries too early (extending the throttle) or waits far too long (stalling the sync). Honor the header and the sync recovers on its own.

```text
429 "you have exceeded your API call limit, retry after 60 seconds"
```

1. Capture a 429 response and read its Retry-After header value. Expected: the header is present and names the wait in seconds.
2. Change the client's 429 handler to sleep for the header's value (defaulting to 60 seconds when the header is absent) instead of a hardcoded delay. Expected: the retry delay now comes from the server, not from a guess.
3. Add jitter to the resumed requests so parallel workers do not all wake up and stampede at the same second. Expected: retries spread out instead of arriving in one burst.
4. Make the wait non-blocking for the rest of the sync: park the throttled worker and let other work continue, or checkpoint progress so the sync resumes where it stopped. Expected: a throttle pauses one worker, not the whole pipeline.
5. Re-run the sync and watch the 429s: they should appear, be honored, and clear without manual intervention. Expected: the sync completes with retries logged and no data loss.

## Use this when
- Lever returns the "retry after 60 seconds" 429 variant during syncs
- The agent currently retries 429s on a fixed short delay and keeps getting throttled
- The sync stalls for far longer than the requested wait because the backoff overshoots

## Not for this skill when
- The 429 has no retry-after guidance at all (use generic exponential backoff instead)
- The error is 401 or 403 (auth problems do not improve with waiting)
- The sync can simply run less often - sometimes the right fix is a slower schedule, not smarter retries

## Variant phrasings
- Lever API retry after 60 seconds handling
- Lever 429 honor Retry-After header
- agent ignoring Lever rate limit retry-after

## Why it happens
Lever's throttle tells the client exactly how long the penalty box lasts, but most generic HTTP clients treat every 429 the same: sleep a fixed few seconds and retry. Retrying at 5 seconds into a 60-second penalty just re-triggers the throttle, and the agent can sit in a retry loop for the whole sync window without ever reading the instruction Lever already gave it.

## Edge cases
- Some proxies strip the Retry-After header; if the header is missing at the agent but present at the edge, check what sits between the agent and Lever.
- A 60-second sleep inside a serverless function can blow the execution timeout; checkpoint and re-invoke instead of sleeping in place.
- Do not treat the header as a suggestion and the throttle as advisory - during the wait window, every call counts against you.

## Provenance

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