Vervoe · Rate Limits

Vervoe Rate Limits

Vervoe does not publish numeric rate limits for its partner/integration API. The public documentation describes REST over HTTPS, standard HTTP status codes, and a signed report webhook, but does not state per-minute request caps, per-account quotas, or candidate-volume ceilings for API use. On the Report Notification Webhook, the documented behavior is that the consumer must return HTTP 200 to acknowledge receipt; if the response is not 200, Vervoe retries delivery. Effective usage ceilings are governed by the employer's plan (candidate volume) rather than a published API rate limit.

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

It captures 3 rate-limit definitions, measuring requests, candidates, and deliveries.

The profile also includes 3 backoff/retry policies defined and response codes documented for success, badRequest, forbidden, notFound, and serverError.

Tagged areas include Hiring, Skills Assessment, Rate Limiting, and Quotas.

3 Limits
HiringSkills AssessmentRate LimitingQuotas

Limits

API Requests account
requests
not published
No fixed numeric request-rate limit is documented for the Vervoe partner API.
Candidate Volume account
candidates
per plan
Effective usage is bounded by the employer's subscription/enterprise plan candidate volume, not a published API rate limit.
Webhook Delivery endpoint
deliveries
retry until acknowledged
The consumer endpoint must return HTTP 200; if not, Vervoe retries sending the report.

Policies

Webhook Acknowledgement
Consumers of the Report Notification Webhook must respond with HTTP 200; a non-200 response triggers Vervoe to retry delivery.
Webhook Signature Verification
Each webhook delivery includes a Vervoe-Signature header (t timestamp and hash) computed as an HMAC SHA-256 over the timestamp concatenated with the raw request body, keyed by the endpoint signing secret from the Vervoe dashboard.
Backoff Strategy
API clients should implement exponential backoff with jitter and honor standard HTTP error semantics (400/403/404/500) returned by the API.

Sources