Greenhouse automations

At sustained throughput, the Harvest API's 50-requests-per-10-second limit gets exhausted fast — and when it does, the HTTP 429 response strips the X-RateLimit-Limit and X-RateLimit-Remaining headers, so your automation loses the context it needs to back off intelligently. Zapier's polling model compounds this: if a burst of applications arrives between poll intervals, events can be skipped entirely with no error logged. Platforms like n8n or Pipedream with proper retry-and-wait logic handle this more gracefully, but you still need to build explicit 429 handling.

Sending parallel write requests to create or update custom field values on candidate records can trigger duplicate field creation — a race condition that was a known Greenhouse bug until August 2024. Even with the fix in place, serializing these requests is safer than assuming concurrent writes are idempotent. On Zapier, there is no native mechanism to throttle parallel Zap executions, meaning a bulk import can fire dozens of simultaneous API calls and still hit this edge case. n8n and Make allow you to enforce sequential processing explicitly.

Greenhouse's Harvest API caps the per_page parameter at 500 records — requests above this return a 422 Unprocessable Entity error rather than silently truncating results. Automations that assume a single API call retrieves all candidates for a job will silently miss records once a role exceeds 500 applicants. The v3 pagination model makes this worse: it only returns a next link with no total count, so you cannot know in advance how many pages to expect, and a failed mid-pagination run in a stateless platform like Zapier has no built-in way to resume from the last successful page.