Willo · Rate Limits

Willo Rate Limits

Willo applies API throttling to the Willo Integration API V2 to keep performance consistent across customers, but does not publish a fixed numeric request-per-minute limit in its public reference. Willo explicitly warns that continuously polling an endpoint for updates, regularly scanning jobs for new or deleted responses, and issuing concurrent calls are the patterns most likely to trigger throttling. The documented guidance is to use webhooks (New Response, Stage Change, New Comment, New Score) for change tracking rather than polling, and to contact Willo to discuss an increased limit for higher-volume needs. Throttled requests return HTTP 429.

Willo Rate Limits is the machine-readable rate-limit profile for Willo on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring requests and concurrency.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Video Interviewing, Recruitment, Rate Limiting, and Quotas.

4 Limits Throttle: 429
Video InterviewingRecruitmentRate LimitingQuotas

Limits

Integration API Requests account
requests
not published (throttled)
Willo throttles the API but does not document a fixed numeric request rate in its public reference.
Polling Behaviour account
requests
discouraged
Continuous polling and repeated job/response scans are the patterns most likely to be throttled.
Concurrent Requests account
concurrency
discouraged
Concurrent calls raise requests-per-unit-time and are more likely to be throttled.
Higher-Volume Limit account
requests
negotiable
Contact Willo to discuss an increased rate limit for higher-volume demands.

Policies

Prefer Webhooks Over Polling
Willo recommends subscribing to webhooks for change tracking and notifications instead of polling endpoints for updates.
Backoff Strategy
On a 429 response, back off exponentially with jitter before retrying rather than retrying immediately.
Avoid Concurrency Bursts
Serialise requests where possible; avoid large numbers of concurrent calls that spike requests per unit time.

Sources