The AI recruitment assistant for any AI agent

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.

Lever