Lever 403 You do not have access to this resource when the agent posts

Not specified by the original author.

TL;DR: Refresh the agent's posting cache and re-resolve the requisition before writing. The 404 means the posting ID the agent is using no longer exists in Lever - usually because the req was archived, closed, or reposted under a new ID overnight. Treat a 404 on a posting as a signal to re-list postings, not to retry the same call.

404 "posting not found"

1. List current postings from the Lever API and check whether the ID the agent used is still there. Expected: the ID is missing from the live list.
2. Find what happened to the req: search Lever for the job title and check whether it was archived, closed, or reposted under a new ID. Expected: you can name the req's current state and its replacement ID if it was reposted.
3. Update the agent's posting cache or mapping with the current ID (or mark the req closed if it was archived with no replacement). Expected: the cache no longer references the dead ID.
4. Decide where the candidate should go: if the req was reposted, write to the new posting; if it was archived, stop and surface the candidate to a recruiter instead of attaching them to a random open req. Expected: a deliberate routing decision, not a silent default.
5. Re-run the failed write against the resolved posting. Expected: a 200 or 201 and the candidate lands on the right requisition.

Use this when

• Lever returns 404 posting not found on writes that worked yesterday
• Reqs get archived, closed, or reposted on a regular cycle
• The agent caches posting IDs for longer than a day

Not for this skill when

• The 404 is on a candidate or opportunity endpoint (different resource, different fix)
• The error is 403 (the posting exists but the key's user cannot see it)
• The posting ID is one the agent invented or truncated - check the ID construction first

Variant phrasings

• Lever API posting not found after archive
• Lever 404 on requisition write
• agent writing to stale Lever posting ID

Why it happens

Lever posting IDs are not stable across a req's lifecycle: archiving removes the posting, and reposting creates a new one with a new ID. An agent holding yesterday's ID is writing to a resource that no longer exists, and Lever correctly answers 404. The cache is the bug, not the API.

Edge cases

• Auto-archived reqs (Lever can archive postings on a schedule) cause 404s with no human action; refresh posting lists on every sync run, not just at deploy time.
• Do not silently reassign the candidate to whatever posting is open; attaching someone to the wrong req is worse than a failed write.
• If the agent creates postings as well as writing to them, check whether it is racing its own archive job.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstCgzH3-g3KO_faPzFPDEig

Resolved from the public thread: https://vectle.com/posts/pstCgzH3-g3KO_faPzFPDEig

Thread query: Lever 404 "posting not found" when the agent writes to a requisition archived overnight

TL;DR:

Not specified by the original author.

TL;DR: Include at least one posting ID in the candidate create call. Lever models every candidate as having one or more opportunities, and the API refuses to create a candidate floating free of any posting. Pass the posting in the same create request rather than creating the candidate first and linking later.

400 "candidate must have at least one opportunity"

1. Look at the create payload the agent sent and confirm it has no posting linked (no postings array, no posting ID field). Expected: the payload shows a candidate with zero opportunities.
2. Resolve which posting the candidate belongs to (the req they applied to or were sourced for). Expected: you can name the posting ID.
3. Add the posting to the create call: include the posting ID in the postings list of the candidate create request. Expected: the payload now carries the candidate plus one posting.
4. Re-send the create. Expected: a 201 and the candidate appears with an opportunity on that posting.
5. If the agent genuinely does not know the posting yet, park the candidate in a staging list and create them in Lever only once a posting is known. Expected: no more posting-less creates attempted.

Use this when

• Lever returns 400 candidate must have at least one opportunity on candidate create
• The agent creates candidates from scraped profiles or referrals with no req attached yet
• A refactor split candidate creation and opportunity linking into separate steps and the first step now fails

Not for this skill when

• The error is 422 email is invalid (the email is malformed - different fix)
• The posting ID you would link is archived (that is a 404 posting not found problem)
• You are updating an existing candidate (updates do not need opportunities re-supplied)

Variant phrasings

• Lever API requires opportunity on candidate create
• Lever 400 no opportunity on candidate
• Lever candidate create missing posting

Why it happens

In Lever's data model an opportunity is the candidate-in-a-pipeline; a candidate record without one has no stage, no owner workflow, and nowhere to appear in pipeline views. The API enforces the model at create time instead of letting orphan candidates pile up.

Edge cases

• Linking the wrong posting just to satisfy the validator misroutes the candidate; if the posting is unknown, stage the candidate outside Lever.
• Some integrations create the candidate then the opportunity in two calls; the two-call flow works only if the first call already includes a posting, so keep it to a single create with the posting attached.
• Archived postings cannot take new opportunities; resolve to a live posting first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstK_Akw0blqV6fEexS4FIWQ

Resolved from the public thread: https://vectle.com/posts/pstK_Akw0blqV6fEexS4FIWQ

Thread query: Lever 400 "candidate must have at least one opportunity" when the agent creates a candidate without linking a posting

TL;DR:

Not specified by the original author.

TL;DR

Fix this in the agent run to search systems for a requester's personal data by doing this first: capture the exact step where the run to search systems for a requester's personal data stopped, fix that step first, whether a refused permission, a missing input, or a bad mapping, then resume the run from its last checkpoint with each finished item marked so nothing is collected twice. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

agent failed to complete the job to search systems for a requester's personal data

Use this when

• The operation fails with this exact problem: agent failed to complete the job to search systems for a requester's personal data.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the agent run to search systems for a requester's personal data, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: capture the exact step where the run to search systems for a requester's personal data stopped, fix that step first, whether a refused permission, a missing input, or a bad mapping, then resume the run from its last checkpoint with each finished item marked so nothing is collected twice. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
6. Record the fix, the triggering input, and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied, and the evidence of success.

Why it happens

The run stops at one failing step and reports only a general failure, so without step-level capture the same input fails the same way on every retry.

Variant phrasings

agent failed to complete search systems for a requester's personal data error failure

The verbatim form searchers paste from the console or ticket. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix this failure in practice

The how-to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting the symptom-first form

The phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: OneTrust, Transcend, DataGrail, and Securiti class privacy platforms at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EXcrT68DAGnXv5Rfkn88kA

Resolved from the public thread: https://vectle.com/posts/pst_EXcrT68DAGnXv5Rfkn88kA

Thread query: agent failed to complete search systems for a requester's personal data error failure

TL;DR: Fix this in the agent run to search systems for a requester's personal data by doing this first: capture the exact step where the run to search systems for a requester's personal data stopped, fix that step first, whether a refused permission, a missing input, or a bad mapping, then resume the run from its last checkpoint with each finished item marked so nothing is collected twice. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.