Ellipse Gradient for Header

Lever Integration Guide

Connect Lever recruiting data with enterprise systems through REST APIs, selected webhook events, OAuth 2.0 or API-key authentication, and Martini workflows.

Lever integration options at a glance

Lever’s primary integration mechanism is its REST API, which provides access to recruiting resources such as Candidates, Opportunities, Postings, Requisitions, Interviews, Offers, Users, and Stages. Lever also supports webhook-style notifications for selected recruiting events, although coverage is not universal for every object or field. OAuth 2.0 and API-key authentication support delegated and account-level integration models. Martini can consume the REST API, receive webhook requests, retrieve authoritative object data, process paginated collections, map JSON, and orchestrate downstream writes. Scheduled workflows, bounded batching, checkpoints, retries, and optional file handling support reliable synchronization and reporting use cases.

Integration pointSupported by Lever?Common use casesHow Martini supports it
REST APIsYesLever’s primary public integration mechanism for retrieving and updating supported recruiting resources, including Candidates, Opportunities, Postings, Requisitions, Interviews, Offers, Users, and Stages.Martini can consume Lever REST endpoints from workflows, authenticate requests, follow pagination, map JSON responses, apply business rules, and write results to downstream systems or Martini APIs.
Webhooks / outbound callbacksLimitedLever provides webhook-style notifications for selected events involving candidates, opportunities, application stages, hiring outcomes, archiving, requisitions, and postings. Coverage is not universal for every object or field.Martini can expose an API or workflow endpoint to receive the notification, validate it, retrieve the current Lever object, and process the event asynchronously when appropriate.
AuthenticationYesLever supports OAuth 2.0 for delegated third-party integrations and API keys for suitable account-level integrations. OAuth access is controlled by scopes and authorizing-user permissions.Martini can store client credentials, API keys, and tokens in protected secrets or environment configuration and use bearer-token or HTTP Basic Authentication patterns as required.
Bulk / asynchronous processingLimitedLever collection endpoints and pagination support batch-oriented retrieval, but a universal bulk or asynchronous API for every object and operation is not confirmed.Martini can implement bounded batching, checkpointed pagination, queued processing, backoff, and object-level failure tracking without assuming a universal Lever bulk endpoint.
File / attachment APIsLimitedCandidate-related files and documents are available for selected resources and require endpoint-, permission-, content-type-, and download-behavior validation.Martini can retrieve supported file metadata or content, route documents, preserve references, and apply receiving-system size, content-type, and malware controls.
Scheduled synchronizationYesScheduled retrieval is suitable for incremental synchronization, reconciliation, reporting extracts, and recovery when webhook coverage is incomplete.Martini can invoke workflows on a schedule, persist cursors or timestamps, process all pages, normalize data, and retry or reconcile failed objects.
Database / analytics accessNot confirmedLever does not expose a public direct operational database interface. Reporting or export options may depend on the account and product configuration.Martini should use confirmed Lever REST endpoints or verified exports rather than assuming direct database access; it can write retrieved data to a supported database or analytics destination.

How Lever exposes data and business events

Lever REST APIs

Lever’s REST API is the primary public mechanism for retrieving and updating supported recruiting resources. Its JSON responses can contain Candidates, Opportunities, Postings, Requisitions, Interviews, Offers, Users, and Stages, subject to endpoint availability, permissions, account configuration, and API version.

Martini implementation pattern

Martini implements a workflow that receives an API or schedule trigger, authenticates against Lever, calls the required endpoint, follows pagination, maps the response into a canonical or downstream model, applies validation and business rules, and writes the result. For webhook-driven processing, the workflow uses the event to identify the object and retrieves the current resource through the REST API.

Implementation sequence

Receive a schedule, API request, or event-driven trigger
Authenticate to Lever with OAuth 2.0 or an API key
Call the relevant Lever REST endpoint
Follow pagination until the collection is complete
Retrieve related objects when the business process requires them
Map Lever JSON into the canonical or target modelій?

Lever Webhooks

Lever supports webhook-style notifications for selected recruiting events, including changes involving Candidates, Opportunities, application stages, hiring outcomes, archiving, Requisitions, and Postings. Notifications should not be treated as a universal stream for every object or field.

Martini implementation pattern

Martini exposes a controlled endpoint or workflow that receives the HTTP notification, validates the request and payload, records the event identifier, and returns promptly. The workflow then retrieves the authoritative Candidate, Opportunity, Posting, or related object from Lever before applying downstream business rules and writes.

Implementation sequence

Receive the Lever webhook notification
Validate the request and reject malformed payloads
Record the event and source object identifiers
Check the idempotency key before processing
Retrieve the current Lever object through the REST API
Apply event-specific routing and business rules

Lever Paginated Synchronization

Lever collection responses may be paginated, making checkpointed scheduled retrieval appropriate for incremental synchronization, reconciliation, analytics extraction, and recovery when webhook coverage is incomplete. A universal bulk API for every object and operation is not confirmed.

Martini implementation pattern

Martini runs a scheduled workflow that stores a cursor, timestamp, or equivalent checkpoint where supported, retrieves bounded pages, and processes each object through mapping and validation logic. It can queue work for controlled asynchronous handling, back off on rate-limit responses, persist failed identifiers, and resume from the last successful checkpoint.

Implementation sequence

Start the scheduled synchronization workflow
Load the last successful cursor or timestamp
Request the next Lever collection page
Map and validate each returned object
Write successful objects to the target system
Persist the next checkpoint and failed object identifiers

Lever Files and Attachments

Lever supports candidate-related files and documents for selected resources, but attachment behavior is endpoint- and permission-specific. Content types, file sizes, download behavior, and privacy controls should be confirmed before implementation.

Martini implementation pattern

Martini retrieves supported file metadata or content after validating the relevant resource and permissions, then routes the document to the approved destination or stores a reference instead of duplicating binary content. The workflow can apply content-type, size, malware-scanning, retention, and error-handling controls.

Implementation sequence

Identify the supported Lever file or document resource
Authenticate with the required permissions
Retrieve metadata and permitted content
Validate size, content type, and privacy rules
Route the file or reference to the destination
Record the source identifier and processing outcome

Common Lever integration patterns

Pattern 1: Sync candidates and opportunities to an HR system

When to use this pattern

Use this pattern when recruiting activity in Lever must create or update worker-related information in an HR platform such as Workday. A checkpointed schedule is useful when the downstream process requires complete incremental retrieval, while selected hiring events can accelerate individual processing.

Integration direction
Lever
Martini
Workday
Example Mapping
Lever FieldCanonical FieldTarget Field
Candidate.idperson.sourceIdWorkday.workerCandidateReference
Candidate.nameperson.nameWorkday.name
Candidate.emailperson.contact.emailWorkday.email
Opportunity.idapplication.sourceIdWorkday.recruitingApplicationReference
Martini implementation pattern

Martini retrieves updated Candidates and Opportunities, follows all pages, and preserves the relationship between the two objects. It maps only candidates reaching the configured hiring stage, validates required fields, performs an idempotent Workday write, stores source and destination identifiers, and retries transient failures without repeating successful operations.

Martini capabilities used
  • scheduled workflows
  • REST API consumption
  • pagination and checkpoints
  • data mapping
  • validation
  • business rules
  • error handling
  • retry and reconciliation

Pattern 2: Trigger onboarding from a hiring event

When to use this pattern

Use this pattern when a selected Lever hiring or stage-change notification should initiate identity, service-management, or onboarding activity. The webhook is a trigger rather than the complete data source, so the current Lever object should be retrieved before creating downstream side effects.

Integration direction
Lever
Martini
Okta
ServiceNow
Example Mapping
Lever FieldCanonical FieldTarget Field
event.typehiring.eventTypeonboarding.triggerType
Opportunity.idapplication.sourceIdServiceNow.sourceReference
Candidate.emailperson.contact.emailOkta.provisioningEmail
Posting.idjob.sourceIdServiceNow.jobReference
Martini implementation pattern

Martini receives and validates the selected webhook, creates an idempotency key from the Lever object and event metadata, retrieves the current Opportunity and Candidate, and applies rules for the relevant hiring outcome. It then routes approved data to Okta, ServiceNow, or an onboarding API, while logging failures for replay or reconciliation.

Martini capabilities used
  • webhook consumption
  • API exposure
  • workflow orchestration
  • REST API consumption
  • data mapping
  • idempotency
  • business rules
  • asynchronous processing
  • error handling

Pattern 3: Publish Lever postings to a careers website

When to use this pattern

Use this pattern when a corporate careers site, job board, or content platform needs normalized job-posting data from Lever. A scheduled workflow can identify new and changed Postings, while a Martini API can provide a controlled normalized view for external consumers.

Integration direction
Lever
Martini
Careers website
Example Mapping
Lever FieldCanonical FieldTarget Field
Posting.idjob.sourceIdCareersWebsite.externalJobId
Posting.titlejob.titleCareersWebsite.title
Posting.locationjob.locationCareersWebsite.location
Posting.descriptionjob.descriptionCareersWebsite.description
Martini implementation pattern

Martini retrieves approved Lever Postings, maps title, location, description, department, status, and stable identifiers, and applies publication rules. It creates or updates the destination item, unpublishes or archives inactive postings when supported, and can expose a normalized REST API so the website is decoupled from Lever’s source model.

Martini capabilities used
  • scheduled workflows
  • REST API consumption
  • API exposure
  • data mapping
  • JSON transformation
  • business rules
  • error handling

Pattern 4: Load recruiting data for analytics

When to use this pattern

Use this pattern when recruiting teams need historical reporting across Candidates, Opportunities, Stages, Interviews, Offers, and Requisitions. It is appropriate for controlled incremental extraction into a reporting database or analytics platform such as Snowflake.

Integration direction
Lever
Martini
Snowflake
Example Mapping
Lever FieldCanonical FieldTarget Field
Candidate.idcandidate.sourceIdrecruiting_candidate.source_id
Opportunity.stageapplication.stagerecruiting_opportunity.stage
Interview.scheduledAtinterview.scheduledAtUtcrecruiting_interview.scheduled_at
Offer.statusoffer.statusrecruiting_offer.status
Martini implementation pattern

A scheduled Martini workflow uses stored checkpoints, pages through each required Lever collection, flattens nested JSON, normalizes timestamps to UTC, and preserves source relationships. It writes bounded batches to the analytics ingestion path, records rejected objects, retries transient API or destination failures, and supports later reconciliation.

Martini capabilities used
  • scheduled workflows
  • REST API consumption
  • pagination and checkpoints
  • JSON transformation
  • data mapping
  • batch processing
  • database or analytics integration
  • monitoring
  • error handling

Applications commonly integrated with Lever

Lever recruiting data can be orchestrated with HR, identity, service-management, collaboration, finance, and analytics applications. The exact object mappings and business rules depend on the organization’s hiring and onboarding processes; Martini can coordinate these flows without treating any downstream application as a hard-coded assumption.

Application Scenario Direction Martini Pattern
Workday Transfer approved hired-candidate information into employee or worker administration processes and reduce manual re-entry during employee creation. Lever → Martini → Workday A scheduled or event-driven Martini workflow retrieves the current Candidate and Opportunity after a hiring event, validates required fields, maps identifiers and employment details, and performs an idempotent Workday write. Failed records are retained for retry and reconciliation.
Okta Initiate identity and access provisioning when a candidate reaches a defined hiring or onboarding milestone. Lever → Martini → Okta Martini receives a selected Lever event, confirms the current Opportunity and hiring status through the REST API, applies provisioning rules, and calls the approved Okta or onboarding endpoint. Duplicate events are suppressed using the Lever object and event identifiers.
ServiceNow Create onboarding tasks, approvals, equipment requests, or service records when a candidate is hired. Lever → Martini → ServiceNow A Martini webhook workflow retrieves the authoritative Candidate, Opportunity, and related Posting data, maps it to ServiceNow request fields, and submits an idempotent task or request. Workflow errors are logged with the source identifiers for controlled replay.
Salesforce Synchronize selected recruiting or talent-program information with broader relationship, organizational, or workforce processes managed in Salesforce. Lever → Martini → Salesforce Martini uses Lever REST retrieval or selected webhook events as the trigger, normalizes Candidate and Opportunity data, applies organization-specific inclusion rules, and upserts the approved Salesforce objects while preserving cross-system identifiers.
Slack Notify recruiting teams or hiring channels about interviews, offers, approvals, and other selected hiring events. Lever → Martini → Slack Martini receives or schedules Lever data retrieval, filters events according to stage and privacy rules, formats a minimal notification, and sends it to the designated Slack endpoint. Sensitive candidate details are excluded from messages unless explicitly required.
Microsoft Teams Deliver recruiting notifications and workflow approvals to hiring teams using Microsoft Teams. Lever → Martini → Microsoft Teams A Martini workflow consumes a Lever event or scheduled change set, maps the event to a Teams notification or approval payload, applies routing rules by requisition or team, and records the delivery result for retry.
NetSuite Pass approved employee or contractor information into finance and workforce-administration processes where NetSuite is used for those records. Lever → Martini → NetSuite Martini retrieves and validates the relevant Lever Candidate and Opportunity, applies hiring-status and field-mapping rules, and sends an idempotent request to the approved NetSuite API or service. Rejected objects are recorded separately from transient failures.
Snowflake Centralize recruiting data for workforce planning, recruiting analytics, and historical reporting. Lever → Martini → Snowflake A scheduled Martini workflow pages through Lever Candidates, Opportunities, Stages, Interviews, Offers, and Requisitions, normalizes timestamps and nested JSON, preserves source identifiers, and writes bounded batches to the approved Snowflake ingestion path.

How to build a Lever integration in Martini

Objective

Establish a controlled connection to Lever using the authentication model appropriate for the integration and keep credentials outside workflow logic.

Instructions in Martini

  • Register or obtain the required Lever OAuth application or API key.
  • Request only the OAuth scopes and permissions required by the selected objects and operations.
  • Store client credentials, tokens, or API keys in Martini secrets or protected environment configuration.
  • Configure the Lever API base URL and authentication behavior for the workflow.

Objective

Select an event-driven, scheduled, or API-led entry point based on Lever event coverage, synchronization requirements, and downstream latency expectations.

Instructions in Martini

  • Use a Martini endpoint or workflow to receive selected Lever webhook notifications.
  • Use a scheduler for incremental retrieval, reconciliation, reporting, or unsupported event coverage.
  • Use an exposed Martini API when downstream applications need a controlled normalized interface.
  • Define the source object, event type, or checkpoint that starts processing.

Objective

Obtain authoritative Lever data rather than relying on a webhook payload as a complete representation of the affected object.

Instructions in Martini

  • Call the relevant Lever REST endpoint after receiving a notification or schedule trigger.
  • Retrieve related Candidates, Opportunities, Postings, Requisitions, Interviews, Offers, Users, or Stages when required.
  • Follow pagination links or cursors until the required collection is complete.
  • Persist a cursor, timestamp, or equivalent checkpoint for incremental workflows.

Objective

Coordinate retrieval, enrichment, routing, and downstream writes as a maintainable Martini workflow with clear processing boundaries.

Instructions in Martini

  • Separate notification intake from expensive retrieval and downstream processing when asynchronous execution is appropriate.
  • Preserve stable Lever identifiers and relationships between Candidates, Opportunities, Postings, and other objects.
  • Apply bounded concurrency and queue work when volumes or destination limits require controlled processing.
  • Make each downstream side effect traceable to a source object and event or synchronization run.

Objective

Convert Lever JSON and account-specific fields into a canonical model or target-system format while tolerating optional properties and custom configuration.

Instructions in Martini

  • Map stable identifiers before display names wherever possible.
  • Normalize timestamps to UTC and retain source timestamps when auditability is required.
  • Flatten nested JSON structures for reporting or downstream APIs.
  • Handle null, missing, optional, and newly introduced fields without failing unrelated objects.

Objective

Use recruiting status, stage, permission, privacy, and destination requirements to determine which data is eligible for downstream processing.

Instructions in Martini

  • Send only candidates or opportunities that meet the configured hiring or stage criteria.
  • Map organization-specific stages and statuses through an explicit cross-reference.
  • Exclude sensitive candidate information from notifications and operational logs unless required.
  • Validate required fields before invoking downstream systems.

Common Lever data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
CandidatesRepresent people participating in the recruiting process and provide candidate identity, contact, profile, and recruiting information.Workday, Okta, ServiceNow, Salesforce, SnowflakeMartini retrieves Candidates through REST endpoints or resolves them after webhook notifications, validates privacy-sensitive fields, preserves the Lever identifier, and maps approved attributes to downstream models.
OpportunitiesRepresent candidate applications or recruiting opportunities associated with a posting and hiring process.Workday, ServiceNow, Salesforce, SnowflakeMartini uses Opportunities to establish recruiting context, correlate Candidates with Postings and Stages, apply hiring-status rules, and perform idempotent downstream upserts.
PostingsRepresent published or internal job postings and their publication, content, location, and status information.Careers websites, job boards, content management systems, SnowflakeMartini retrieves and transforms Postings, publishes approved changes, unpublishes or archives inactive items, and retains the Lever posting identifier in the destination.
RequisitionsRepresent internal hiring requests associated with recruiting activity and workforce planning.ServiceNow, Workday, SnowflakeMartini maps Requisitions to approved downstream requests or reporting structures, handles optional and account-specific fields, and records source identifiers for reconciliation.
InterviewsRepresent interview events and related scheduling information for candidates and opportunities.Slack, Microsoft Teams, ServiceNow, SnowflakeMartini can retrieve Interviews, normalize times to UTC, apply notification or reporting rules, and route only the required information to downstream systems.
OffersRepresent offers associated with Candidates and Opportunities, including offer-related status or outcome information where available.Workday, ServiceNow, SnowflakeMartini validates access and privacy requirements, maps offer status and identifiers, applies approval or hiring rules, and separates rejected or failed writes for reconciliation.

Authentication and security considerations

OAuth 2.0 and API keys

Lever supports OAuth 2.0 for delegated integrations and API keys for suitable account-level integrations. OAuth access is governed by requested scopes and the permissions of the authorizing Lever user.

  • Store client credentials, access tokens, and API keys in Martini secrets or protected environment configuration.
  • Request only the read and write scopes required by the workflow.
  • Rotate API keys and client credentials according to organizational policy.
  • Use bearer authentication for OAuth requests and the documented HTTP Basic Authentication pattern for API keys.

Recruiting data protection

Candidates, Offers, Interviews, and related recruiting objects may contain personally identifiable or sensitive employment information.

  • Restrict Martini APIs and workflows to authorized users and applications.
  • Avoid logging resumes, personal contact details, and sensitive payload content.
  • Protect data in transit and at rest and define retention and deletion behavior.
  • Validate webhook requests and keep event intake separate from expensive processing where appropriate.

Operational considerations for Lever integrations

Rate limits and pagination

Lever requests may be subject to account and endpoint rate limits, and collection responses may be paginated. Martini workflows should follow cursors or links, avoid unbounded parallelism, honor Retry-After when supplied, and use bounded exponential backoff.

Idempotency and reconciliation

Webhook deliveries and scheduled runs can overlap or repeat. Use stable Candidate, Opportunity, Posting, Requisition, Offer, or event identifiers to create idempotency keys, and make downstream writes safe to retry.

Schema and account variation

Optional fields, custom fields, pipeline stages, permissions, and posting metadata vary by Lever account. Mappings should tolerate missing values and new fields, use stable identifiers where possible, and maintain explicit status cross-references.

Testing and monitoring

Test representative webhook events, paginated collections, permission failures, rate-limit responses, deleted objects, malformed payloads, and downstream errors. Record workflow outcomes and failed object identifiers without exposing sensitive candidate data.

Files and privacy

Candidate file and attachment processing is endpoint- and permission-specific. Confirm content types, size limits, download behavior, retention, and malware-scanning controls before transferring documents.

Why use Martini instead of scripts or point-to-point integrations?

Coordinate more than an API call

Scripts can call Lever, but production integrations also need authentication management, pagination, checkpoints, mappings, status rules, idempotency, retries, privacy controls, and downstream coordination. Martini provides a workflow-based way to keep these concerns visible and maintainable.

Support multiple integration styles

Martini can consume Lever REST APIs, receive selected webhook notifications, expose controlled APIs for downstream consumers, and run scheduled or asynchronous workflows. This allows event-driven processing and reconciliation to coexist rather than forcing every use case into one point-to-point flow.

Improve reuse and operations

Reusable mappings, validation logic, secrets, error handling, and transformation steps reduce duplicated integration code. Checkpoints, bounded processing, monitoring, and recorded failures help teams operate recruiting synchronizations without losing the relationship between source objects and downstream actions.

Frequently asked questions

How can Lever be integrated with enterprise systems?

Lever can be integrated through its REST APIs, selected webhook-style event notifications, OAuth 2.0, API keys, and supported candidate file or document endpoints. Enterprise workflows commonly retrieve or receive Candidates, Opportunities, Postings, Requisitions, Interviews, Offers, Users, and Stages, then map them into HR, onboarding, collaboration, service-management, or analytics systems.

Can Martini integrate with Lever?

Yes. Martini can integrate with Lever by consuming Lever’s REST APIs, receiving selected webhook notifications, authenticating with OAuth 2.0 or an API key, processing paginated JSON, and orchestrating scheduled, event-driven, or asynchronous workflows. A native Martini Lever connector is not documented in the supplied sources.

Do I need a connector to integrate Lever with Martini?

No. A dedicated Lever connector is not required. Martini can use Lever’s confirmed native integration mechanisms, including REST APIs, selected webhook events, OAuth 2.0, API-key authentication, and supported file or attachment endpoints.

Is there any extra Lonti cost to integrate Lever with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Lever. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Lever, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.

Which Lever integration methods should a new implementation use?

New implementations should generally use Lever’s REST APIs for authoritative resource access and its documented webhook capabilities for selected event-driven use cases. OAuth 2.0 is appropriate for delegated integrations with scopes, while API keys can suit account-level integrations where that credential model is approved. Lever GraphQL and SOAP APIs were not confirmed as supported public mechanisms.

Can Martini receive Lever webhook events?

Yes. Lever supports webhook-style notifications for selected events involving areas such as Candidates, Opportunities, application stages, hiring outcomes, archiving, Requisitions, and Postings. Coverage is not universal, so the required event types should be confirmed. Martini can receive the notification, validate it, deduplicate it, and retrieve the current Lever object through the REST API.

How does synchronization between Lever and another system work?

Martini can run scheduled or event-driven synchronization workflows. Scheduled flows follow Lever pagination, retain a cursor or timestamp checkpoint, preserve stable object identifiers, and perform idempotent upserts. Event-driven flows use the notification to locate the affected object and then retrieve current data. Business rules, status cross-references, retries, and reconciliation can be applied before downstream writes.

How are Lever errors, retries, and duplicate events handled?

A Martini workflow can distinguish authentication, permission, validation, rate-limit, temporary server, missing-object, and downstream failures. It can honor Retry-After, apply bounded exponential backoff, record failed object identifiers, and resume from checkpoints. Stable Lever object IDs plus event metadata can form idempotency keys so duplicate webhook deliveries or reruns do not repeat successful side effects.

Related Martini documentation

API Workflows

Orchestration

Data Processing

Security

Operations

Connect Lever with Martini

Use Martini to build secure, maintainable Lever integrations that synchronize recruiting data, respond to selected hiring events, and coordinate downstream enterprise workflows.

EXPLORE MARTINI
BOOK A DEMO