A recruiter asks an AI assistant to prepare notes for a list of candidates. Each worker fetches a record, reads supporting data and checks the record again before saving a draft. The small batch becomes a burst of requests. Some calls fail, workers retry together, and the next run starts while the first is still recovering. The operator sees incomplete work without knowing which candidates were processed.
A dependable Lever integration needs request control and a record of progress before it needs more parallel workers. The following design separates documented Lever behavior from engineering recommendations for your own connector. It focuses on the authenticated v1 API, not public job application submissions.
Understand the request budget you actually have
Lever documents rate limiting by API key using a token bucket. Its published default is a steady 10 requests per second per key, with bursts up to 20 requests per second when possible. Those defaults are not guaranteed. Lever says they can vary with server load and change in the future. It recommends exponential backoff.
Do not interpret that description as a throughput promise. A scheduled sync and an AI worker using the same key consume the same key budget. Adding workers does not create extra capacity for that credential. As an engineering choice, route their requests through a shared limiter and reserve room for operational checks. Start conservatively, measure actual responses and lower concurrency when the service rejects traffic.
Define one small recruiting workflow first
Write down what the connector is allowed to do. A useful first workflow reads an approved set of candidate records and prepares an internal summary for recruiter review. Keep automatic outreach, stage changes and other consequential updates outside that initial scope. Reviewers should see the source record and the proposed result together.
Separate read access from the application decision to permit a write. Credentials belong in a protected server component, not model prompts or browser code. An AI model should request a named operation through that component rather than assemble arbitrary API calls. Our recruiting AI agents approach starts with this bounded unit of work.
Classify failures before choosing a retry
Lever documents different HTTP responses for different failures. A malformed request is not the same problem as exhausted capacity. Preserve the response status and a safe error summary so the next action follows the actual failure. Do not dump candidate details or credentials into diagnostic logs.
| Response | Documented meaning | Recommended handling |
|---|---|---|
| 400 | Missing or malformed request parameter | Correct the request before resubmitting |
| 401 | Valid API key was not provided | Pause and investigate authentication |
| 403 | Account settings do not authorize the operation | Ask the responsible administrator to review access |
| 404 | Unknown action or missing object | Check path, method and record reference |
| 429 | Too many requests in a short time | Reduce traffic and retry with a bounded backoff |
| 503 | Temporary unavailability for maintenance | Retry with exponential backoff |
For temporary read failures, use an increasing wait between attempts, add random variation and cap both attempts and total time. These are connector design choices, not an additional Lever guarantee. When the budget ends, keep the work pending with a clear error. Do not silently label it complete or allow another scheduler to restart it immediately.
Follow pagination tokens exactly
Lever documents pagination on list endpoints such as opportunities, users and postings. The limit parameter supports 1 to 100 items. A paginated response includes a next attribute carrying an offset token for a following request. Only use an offset returned by a previous paginated response. Omitting the offset starts at the first page.
Store the original filters, endpoint and cursor together. A cursor without its query context is not enough to explain what the connector has covered. Do not construct offsets from row counts or page numbers. Keep a set of processed record identifiers within the run so repeated data cannot trigger the same work twice.
Save progress after the page has been durably handled, not as soon as it arrives. If a worker stops between fetching and saving its output, the run should resume from a known checkpoint. Detect a repeated cursor or a page that contributes no new records, then stop for investigation instead of looping. These checks make incomplete retrieval visible.
Keep AI processing outside the API request loop
Fetch an approved batch, record its coverage, then let model workers prepare results from that saved input. A model retry should not automatically refetch the entire candidate set. Likewise, a network retry should not cause a second model run when a valid draft already exists. Track those activities separately.
Bind each draft to the candidate identifier and the input version your application observed. Show uncertainty explicitly when source material is missing. Before applying an approved update, reread the relevant current state and compare it with the reviewed draft. If a recruiter changed the record in the meantime, pause the update rather than overwriting newer work.
Reconcile uncertain writes before replaying
A timeout tells the connector it did not receive a usable answer. It does not establish whether the server applied the request. Repeating a create or an additive action without checking can duplicate work. Build an operation journal in your own system with a stable work identifier, target record, intended action and observed result.
After an ambiguous write, inspect the relevant target state through the documented read operation for that resource. Mark the journal complete if the intended change is confirmed. Retry only when the application can establish that doing so is safe. If it cannot distinguish an existing result from a new action, send the case to an operator. Do not assume every endpoint offers an idempotency feature.
Test interruption and recovery, not just a happy batch
- Run the permitted read workflow against a controlled set of records.
- Simulate a rate rejection and confirm all workers slow down together.
- Interrupt processing after a page is fetched and before its output is saved.
- Resume and verify that every intended record has one final result.
- Simulate a timeout after a write and verify that reconciliation runs before replay.
- Change a reviewed record before submission and confirm the connector pauses.
Keep a run summary with requested scope, processed identifiers, unresolved records and the last verified checkpoint. A green job status without these counts is weak evidence. Operations staff need to know whether a run covered its intended set and what remains blocked. Our recruiting stack integration guide covers the surrounding system ownership decisions.
Common mistakes that make recovery harder
- Giving every worker an independent limiter for the same key.
- Retrying authorization failures as if they were temporary overload.
- Saving the next cursor before the current page is processed.
- Using model success as proof that an ATS write succeeded.
- Recording full candidate payloads in general application logs.
- Starting a replacement run while unresolved writes remain in flight.
How Remqa helps with Lever recruiting integrations
Remqa builds recruiting AI workflows and the integration code around them. We can help define the permitted actions, coordinate API traffic, track batch coverage and create a review path for uncertain results. The work should be scoped to your Lever access and the workflow your recruiters actually use. If a connector is moving data between systems, our ATS migration work can address mapping and reconciliation too. Bring one repetitive recruiting task and its current failure cases to an initial conversation.