Workable · Rate Limits
Workable Rate Limits
Workable enforces per-token rate limiting on its v3 REST API. The documented default is a sliding-window bucket per access token; clients receive HTTP 429 with Retry-After when the bucket is exhausted. Dedicated read-only public endpoints (job feeds) are not rate-limited the same way.
3 Limits
Throttle: 429
HRATSRecruitingRate LimitingThrottling
Limits
Per Access Token Default token
Sliding-window per-token limit; 429 returned with Retry-After when exceeded. Inspect X-Rate-Limit-Limit / X-Rate-Limit-Remaining / X-Rate-Limit-Reset response headers.
Listing Endpoints token
List endpoints (e.g. /jobs, /candidates) are paginated and weighted higher than single-record retrievals; paginate aggressively.
Webhook Delivery subscription
Workable webhooks are delivered with retries on 5xx. Receivers must respond 2xx within the platform timeout to avoid retry loops.
Policies
Backoff Strategy
Exponential backoff with jitter on 429 and honor any Retry-After header. Avoid tight retry loops on listing endpoints.
Pagination
Use since_id and limit cursors on candidate / activity endpoints to page through historical data without exhausting the rate limit.
Webhooks-First
Subscribe to candidate.* and member.* events for change feeds; reduce poll frequency on listing endpoints accordingly.