API Rate-Limit Questions for Vendors

An API can appear fast in a demo and still fail when a recruiting team runs a morning import, refreshes a shortlist or retries a timed-out write. Ask vendors to explain what is counted, over which window, for which identity and what the client should do next. This commercial-investigation guide is for a recruiting operations lead at the troubleshoot stage, not a capacity guarantee or security assessment. Keep an answer unknown until it is written, dated and tested.

Start with one reproducible scenario

Send every shortlisted vendor the same small scenario. State the endpoint or workflow, request count, payload size, pages, peak pattern, concurrent workers, environment, geography and whether requests are reads or writes. Ask for the limit on the quoted plan and the answer's source: current documentation, contract, dashboard or test result.

Use this question in the first review:

For this exact scenario, what limits apply, how will the client observe them, what response will it receive when a limit is reached, and what recovery is supported without duplicate or missing records?

Do not compare a per-minute number with a daily quota as if they were the same unit. Ask whether a limit is hard, soft, shared, separately metered or subject to fair-use wording. Record the plan name, documentation version and answer date because limits can vary by endpoint, environment or account.

Questions that expose the real limit

The IETF's RateLimit header fields specification, published in August 2023, gives a vocabulary for limit, remaining capacity and reset time, but does not require those fields or prove an implementation. RFC 6585, published in April 2012, defines status 429; RFC 9110, published in June 2022, defines HTTP semantics including Retry-After. Use these dated references to make questions precise, not to infer a vendor's behaviour.

Troubleshoot a limit without guessing

When a client receives a 429, save the timestamp, endpoint, method, request ID, headers, body, client identity, concurrency and local quota counters. Check for a retry time. Honour a valid Retry-After; otherwise use bounded exponential backoff with jitter, an attempt limit and a circuit breaker. Route exhausted work to a durable queue or manual review so a restart does not silently skip it.

Separate retryable transport failure from an accepted asynchronous request. A timeout after a write is ambiguous: query the resource or replay with the vendor's idempotency mechanism before creating another record. Ask whether an idempotency key is scoped to an endpoint, account or payload, and what happens if the same key is reused with a changed body. A structured error can help a client classify a response; RFC 9457, published in July 2023, describes HTTP Problem Details, but it does not mean a vendor implements that format.

Pagination and concurrency often hide failure. Test a result set crossing a page boundary, an expired cursor, a changed record between pages and a worker restart. Measure in-flight requests, page gaps, duplicates, latency and 429 responses. If the vendor only says "use reasonable traffic", ask for a numeric boundary or mark the pilot condition unresolved.

Run a hiring pilot with stop conditions

Illustrative scenario: a recruiting operations lead evaluates a vendor API that enriches 200 synthetic candidate records for one approved role. The pilot uses 20 records per page, two workers, a burst of 10 requests, a forced 429, a timeout after one write and a saved-cursor resume. It contains no real CVs or contact details. The lead records plan, request and page counts, timestamps, status and rate headers, request IDs, duplicates, missing records, retry delay, alert and vendor response. This is a test fixture, not a capacity benchmark.

Before the pilot, agree the last-known-good export, queue or cursor, idempotency approach, owner and rollback action. Rollback may pause calls, quarantine queued work, restore the mapping or switch to manual review; it should not silently delete records. Stop when a 429 cannot be bounded, Retry-After is ambiguous without a fallback, a timed-out write cannot be reconciled, pagination can skip records, monitoring has no owner or the quote omits a billable unit. Continue only with a named owner, due date and authorised exception.

Use this compact decision record:

VENDOR API RATE-LIMIT REVIEW
Vendor, API/version, plan and answer date:
Scenario, environment, endpoint and expected volume:
Quota scope, unit, window, burst and concurrency:
429, Retry-After, rate headers and error-body evidence:
Pagination, cursor, retry and idempotency evidence:
Usage dashboard, alerts, request IDs and retention:
Support route, escalation terms and owner:
Supplier cost, overage, retry charges and internal effort:
Pilot fixtures, observed result and known defect:
Rollback, manual fallback and stop condition:
Decision: PASS / PILOT WITH CONDITIONS / STOP
Owner, exception due date and next review:

Where Talent Summoner fits

Talent Summoner is our product for candidate sourcing and ranking, not a general API integration or ATS. Candidate sourcing starts from an approved role brief and returns public-source discovery for human review. Candidate ranking reviews supplied CVs; neither page documents API quotas, webhooks, automated outreach, applicant-pipeline management or bidirectional synchronisation. Keep exports or manual hand-offs with the recruiting operations owner, and use pricing only after the boundary is clear.

Take one representative workflow to each vendor, preserve the dated answers and raw test evidence, then choose PASS, PILOT WITH CONDITIONS or STOP. For upstream discovery, review candidate sourcing; for CVs already supplied, use candidate ranking and keep the integration review separate.