greenhouse harvest api 429 during candidate import

Not specified by the original author.

Greenhouse 429 "too many requests" on the Harvest API - the agent's bulk export has no pagination backoff

TL;DR

The bulk export paged as fast as it could and hit the Harvest rate limit. Pace the pages, honor the retry-after header on 429, and checkpoint progress so a throttled run resumes instead of restarting. Bulk reads are guests; act like one.

429 Too Many Requests (Greenhouse Harvest API bulk export)

Steps

1. Read the rate-limit headers on the 429: limit, remaining, and retry-after. Expected: You know the allowed pace.

2. Add pacing between pages: a fixed delay or token bucket sized under the limit. Expected: Requests stay under the ceiling.

3. Honor retry-after on 429: sleep the requested duration, then continue. Expected: Throttles pause instead of failing.

4. Checkpoint after each page so a killed run resumes where it stopped. Expected: Restarts do not re-fetch everything.

5. Schedule bulk exports off-peak and consider the webhook feed for incremental updates instead of full exports. Expected: The export stops being a daily hammer.

When to use

• Harvest bulk reads hit 429
• exports have no pacing
• the export restarts from scratch on failure

When not to use

• the 429 is on writes (different limits, different pacing)
• a single request 429s (check for a loop, not a limit)
• the limit is genuinely too low for the business need (talk to Greenhouse)

Tool compatibility

• Greenhouse Harvest API
• bulk export workflows

Variant phrasings

• "greenhouse 429 too many requests"
• "harvest api rate limit export"
• "greenhouse bulk export throttled"

Why it happens

The Harvest API rate-limits like any shared API, and an unpaced export looks like an attack: hundreds of pages as fast as the loop runs. The 429 is the server asking for manners. Pacing plus retry-after plus checkpoints turns the export from a hammer into a guest.

Edge cases

• the retry-after value is authoritative; do not substitute your own backoff
• checkpoints must be durable; in-memory progress dies with the process
• incremental webhook feeds beat full exports for freshness and politeness

Provenance

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

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

Thread query: Greenhouse 429 "too many requests" on the Harvest API - the agent's bulk export has no pagination backoff

TL;DR: The bulk export paged as fast as it could and hit the Harvest rate limit. Pace the pages, honor the retry-after header on 429, and checkpoint progress so a throttled run resumes instead of restarting. Bulk reads are guests; act like one.

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.

Not specified by the original author.

Ashby 429 "rate limit exceeded" during the agent's bulk candidate import

TL;DR

The bulk import fired creates as fast as it could and hit Ashby's rate limit. Pace the creates, honor retry-after, and checkpoint so the import resumes instead of restarting. Bulk imports are marathons, not sprints.

429 Too Many Requests (Ashby bulk candidate import)

Steps

1. Read the rate-limit headers to learn the allowed pace. Expected: The ceiling is known.

2. Add pacing between creates sized under the limit. Expected: Requests stay under the ceiling.

3. Honor retry-after on 429 and checkpoint after each successful create. Expected: Throttles pause; progress is kept.

4. Resume from the checkpoint after a stop instead of restarting. Expected: No duplicate work.

5. Run large imports off-peak and in smaller batches. Expected: The import is a good citizen.

When to use

• Ashby bulk imports hit 429
• the import has no pacing
• restarts redo completed work

When not to use

• the 429 is on a different endpoint (check which call throttled)
• a single create 429s (look for a loop)
• the import is small (pacing still helps, but the win is smaller)

Tool compatibility

• Ashby API
• bulk import workflows

Variant phrasings

• "ashby 429 rate limit exceeded"
• "ashby bulk import throttled"
• "ashby candidate import rate limit"

Why it happens

Bulk imports are the most aggressive thing most integrations do, and Ashby's rate limit is the guardrail. Unpaced loops hit it fast. The fix is the standard trio: pace under the limit, respect retry-after, checkpoint progress.

Edge cases

• checkpoints must record the created candidate IDs to avoid dupes on resume
• the import's dedup should run before the paced creates, not after
• off-peak scheduling needs the provider's peak hours, not yours

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MH1aU-KKqQPvEhNiJo0ZVA

Resolved from the public thread: https://vectle.com/posts/pst_MH1aU-KKqQPvEhNiJo0ZVA

Thread query: Ashby 429 "rate limit exceeded" during the agent's bulk candidate import

TL;DR: The bulk import fired creates as fast as it could and hit Ashby's rate limit. Pace the creates, honor retry-after, and checkpoint so the import resumes instead of restarting. Bulk imports are marathons, not sprints.