Lever

Lever calls a job a posting.

Access

Lever is BYOK-only. Connect your own Lever API key in Integrations; a Lever Super Admin mints it under Settings → Integrations and API. There is no managed-key fallback and the write costs 0 Hyreflow credits. list_users is the free connection check: it verifies the key and returns the users a perform_as comes from.

Every write needs a perform_as user

Lever has no system actor — every posting is attributed to a real Lever user, passed as perform_as in the payload; it is sent as the query parameter Lever requires, not as a body field. That user becomes the creator and, unless owner says otherwise, the owner. Ask the user whose Lever account the posting should be created under; do not guess.

Create a posting

create_job(payload) posts a job. Required: perform_as and text, plus categories.team, categories.department and categories.location.

• perform_as (required) — the Lever user the posting is created as; sent as a query parameter.
• text (required) — the posting title.
• categories.team / categories.department / categories.location (all required).
• categories.commitment — Full-time, Part-time, Internship, …
• categories.allLocations — additional locations.
• state — published, internal, closed, draft, pending, rejected — defaults to draft.
• distributionChannels — internal, public — defaults to BOTH.
• owner / hiringManager — Lever user ids.
• tags — extra posting tags.
• content.descriptionHtml, content.lists ([{text, content}]), content.closingPostingHtml.
• salaryDescriptionHtml, salaryRange ({currency, interval, min, max}).
• workplaceType — onsite, remote, hybrid.
• requisitionCodes.

hyreflow tools execute lever_create_job --payload '{
  "text": "Senior Platform Engineer",
  "state": "draft",
  "categories": {"team": "Engineering", "department": "Technology", "location": "Berlin"},
  "perform_as": "8d49b010-cc6a-4f40-ace5-e86061c677ed"
}'

The posting id is data.id; data.urls carries the live list/show/apply links once published.

Publishing it

set_job_state(posting_id, perform_as) is a partial update — POST /postings/{id} — that changes only what it sends. state defaults to published, taking a draft posting live on the sites named by its distributionChannels.

hyreflow tools execute lever_set_job_state --payload '{
  "posting_id": "730e37db-93d3-4acf-b9de-7cfc397cef1d",
  "perform_as": "8d49b010-cc6a-4f40-ace5-e86061c677ed"
}'

The same call moves a posting to any other state — internal, closed, draft, pending, rejected — and takes an optional payload of the create fields to change alongside it. Read the posting first so a partial update doesn't clobber a concurrent edit in Lever Hire; updating through the API skips the approvals chain, exactly like creating does.

Gotchas

• state defaults to draft — the posting is not live unless "state": "published" is sent.
• distributionChannels defaults to BOTH public and internal — say ["internal"] to keep it internal.
• Creating through the API skips Lever's approvals chain; a confidential posting can't be created at all.
• Lever paces at 10 requests/second per key — don't parallelize a batch on top of that.
• This is a write into the customer's own ATS — confirm state and distributionChannels before executing.

What creating a posting does NOT do

• It does not publish by default — state is draft unless told otherwise.
• It does not route through Lever's internal approvals chain.
• It cannot create a confidential posting at all.