Lever

This page records how composerID publishes into Lever: the vendor’s API posture, the publish target and field mapping, and the documentation each claim rests on. It is for anyone evaluating the connection or building against it. Lever is an ATS with a candidate-centric (Opportunity) model - the recruiting system of record on the permanent-hiring channel. composerID creates the Requisition with requisitionCode = Intent ID, opens the Posting against it, and back-syncs offers and hires through signed webhooks and archive-as-hired-against-requisition.

Category: ATS. Coverage status: Specification mapped. Vendor documentation: public developer portal.

Integration path

How composerID connects to this destination, at a glance.

Step	Detail
Authentication	API key over HTTP Basic (key as username) for private integrations - keys carry per-endpoint permissions and an explicit confidential-data grant set at creation; OAuth 2.0 (1-hour tokens) for partner apps, EU instances supported.
composerID publishes	Requisition: POST /v1/requisitions
Intent ID lands on	`requisition` `requisitionCode`, written into the destination record
Back-sync	Webhooks: the destination pushes events; composerID verifies each delivery and lands it on the intent’s timeline.

Vendor documentation

Lever Data API documentation

API changelog

Public Postings API (job boards)

API posture

Aspect	Detail
Authentication	API key over HTTP Basic (key as username) for private integrations - keys carry per-endpoint permissions and an explicit confidential-data grant set at creation; OAuth 2.0 (1-hour tokens) for partner apps, EU instances supported. Writes attribute to a real user via the perform_as parameter.
Style	REST, JSON at /v1; offset-token pagination (opaque next tokens); separate unauthenticated v0 Postings API for public job boards
Base URL	https://api.lever.co/v1 (EU instance and sandbox available)
Webhooks	UI-configured with a signing token; HMAC-SHA256 signature delivered in the request body (verify + cache tokens against replay). Events incl. candidate hired, stage change, archive, interviews, contacts. Persistent endpoint failures disable the webhook - ack fast, process async.
Events posture	Webhooks
Rate limits	10 req/s per key (token bucket, ~20 burst); POSTs throttle lower (~2/s); 429 with Retry-After.
Objects	requisitions (requisitionCode, headcountTotal, compensationBand, customFields, approvals), postings, opportunities (candidate-centric), applications, offers (incl. signed documents), archive reasons, requisition_fields

Publish target and field mapping

Each object below pairs the canonical intent fields with the destination’s own fields and operations. The mapping is indicative until it is confirmed against a tenant at onboarding.

Requisition

Open the approved demand

Mapping	Detail
Canonical to destination	requisitionCode = intent_id, name, headcountTotal, compensationBand, customFields
Target	POST /v1/requisitions
Requirement	Required
Notes	requisitionCode is queryable - the natural Intent ID carrier

Posting

Publish the role

Mapping	Detail
Canonical to destination	role_title, team, location, requisitionCodes[]
Target	POST /v1/postings?perform_as={userId}
Requirement	Required
Notes	API-created postings skip the approval chain unless created as drafts

Hire back-sync

Close the loop

Mapping	Detail
Canonical to destination	offer signed, candidate hired against the requisition
Target	Signed webhooks + archived-as-hired (requisitionId)
Requirement	Required
Notes	Hiring against a requisition ties the Opportunity back to the Intent ID

Key scoping is decided at creation: endpoint permissions and confidential-data access cannot be widened later without a new key - request exactly what publishing needs. Requisition custom fields are tenant-defined (requisition_fields endpoint). Webhook signatures arrive in the body, not a header, and Lever disables webhooks after sustained failures - return 200 immediately and queue. EU tenants live on the EU instance.

Next steps

How composerID connects

The five ways composerID reaches a destination, and the minimum a destination must offer.

Publishing

Plan, preflight and publish: how a decision becomes a valid record in a destination.

All destinations

Every destination composerID documents, with its category and coverage status.

⌘I

Get started

Concepts

Guides

Destinations

Upstream connectors

API reference

Endpoints

Manuscript API (Triage)

Manuscript endpoints

Resources

Integration path

Vendor documentation

Lever Data API documentation

API changelog

Public Postings API (job boards)

API posture

Publish target and field mapping

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

Lever Data API documentation

API changelog

Public Postings API (job boards)

​API posture

​Publish target and field mapping

​Next steps

How composerID connects

Publishing

All destinations

Integration path

Vendor documentation

API posture

Publish target and field mapping

Next steps