hyreflow
Integrations

Lever

Post a job to Lever: title, team/department/location categories, description, requirement lists, workplace type, salary range, tags and requisition codes. BYOK-only, production writes.

Lever calls a job a posting. Use Lever to stand up a posting in the customer's ATS, and publish it. It is a write target — Hyreflow reads only the user list, to resolve a perform_as and verify the key.

Free (BYOK). Lever writes cost no credits. Connect your own Lever API key from the dashboard Integrations page. A Lever Super Admin mints the key under Settings → Integrations and API; access to confidential objects is granted when the key is created, not later. list_users is the free connection check: it verifies the key and returns the users a perform_as comes from.

Capability

ToolDoesCost
create_jobCreate a posting as a given user (draft unless state says otherwise)Free
set_job_statePublish a posting (or move it to another state), as a given userFree

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. 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 an id.

create_job parameters

FieldTypeRequiredNotes
perform_asuser idyesThe Lever user the posting is created as. Sent as a query parameter, not in the body.
textstringyesTitle of the posting.
categories.teamstringyesThe team the posting belongs to, e.g. Engineering.
categories.departmentstringyesThe department the team sits in.
categories.locationstringyesThe job's location.
categories.commitmentstringnoWork type, e.g. Full-time, Part-time, Internship.
categories.allLocationsarray of stringnoAdditional locations.
statestringnopublished, internal, closed, draft, pending, rejected. Defaults to draft.
distributionChannelsarray of stringnointernal, public. Defaults to BOTH.
owneruser idnoWho manages applicants. Defaults to perform_as.
hiringManageruser idnoThe hiring manager for the posting.
tagsarray of stringnoAdditional posting tags.
content.descriptionHtmlstringnoTop-of-page description, HTML limited to Lever's subset.
content.listsarray of {text, content}noRequirement/responsibility lists; content is HTML.
content.closingPostingHtmlstringnoCustom closing statement, appended to any closing template.
salaryDescriptionHtmlstringnoFree-text salary blurb, HTML.
salaryRange.currencystringnoISO currency code, e.g. USD.
salaryRange.intervalstringnoPayment interval, e.g. per-year-salary.
salaryRange.minintegernoBottom of the range.
salaryRange.maxintegernoTop of the range.
workplaceTypestringnoonsite, remote, hybrid.
requisitionCodesarray of stringnoRequisition codes to associate with the posting.

perform_as (Lever user id, required) travels in the payload like any other field, and is sent as the query parameter Lever requires rather than as part of the posting body.

hyreflow tools execute lever_create_job --payload '{
  "text": "Senior Platform Engineer",
  "state": "draft",
  "categories": {"team": "Engineering", "department": "Technology",
                 "location": "Berlin", "commitment": "Full-time"},
  "content": {"descriptionHtml": "<p>Own the deployment platform.</p>",
              "lists": [{"text": "Requirements", "content": "<ul><li>Kubernetes</li></ul>"}]},
  "workplaceType": "hybrid",
  "perform_as": "8d49b010-cc6a-4f40-ace5-e86061c677ed"
}'

The response is {data}; the posting's id is data.id, and data.urls carries the live list/show/apply links once it's published.

state defaults to draft — the posting is not live unless you send "state": "published". distributionChannels defaults to BOTH public and internal — an internal-only posting must say ["internal"] explicitly. Confirm both with the user before executing; publishing is the irreversible half of this call.

set_job_state parameters

set_job_state is a partial update — POST /postings/{id} — that changes only what it sends.

FieldTypeRequiredNotes
posting_idstringyesThe posting to update.
perform_asuser idyesThe Lever user performing the update. Sent as a query parameter.
statestringnopublished, internal, closed, draft, pending, rejected. Defaults to published.
payloadobjectnoAny of the create_job fields, to change alongside the state.
hyreflow tools execute lever_set_job_state --payload '{
  "posting_id": "730e37db-93d3-4acf-b9de-7cfc397cef1d",
  "perform_as": "8d49b010-cc6a-4f40-ace5-e86061c677ed"
}'

state defaulting to published takes a draft posting live on the sites named by its distributionChannels.

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.

What creating a posting does not do

  • It does not publish by default — state is draft unless told otherwise.
  • Creating through the API skips Lever's approvals chain. If the client runs approvals, create as draft and let them route it inside Lever Hire.
  • A confidential posting cannot be created through the API at all.

Lever paces at 10 requests/second per key. Hyreflow already spaces calls — don't parallelize a batch of postings on top of that.

On this page