Lever → Ashby

Catalog plan outline

General guidance from the Afterstack catalog for Lever → Ashby. Not Lever or Ashby vendor documentation.

Migration friendliness

Lever 6/10 · Ashby 6/10

Speed to live

Lever 5/10 · Ashby 6/10

Catalog migration difficulty

Lever high · Ashby medium

Data to export from Lever

• pipeline and deal records
• synced email and calendar links
• workflow rules
• saved reports
• installed marketplace apps
• AI assistant configuration
• records for the catalog use cases: ats

How the catalogs differ

• Neither product is flagged for custom objects. Keep the object list short.
• Lever is flagged with an open API, which is the export path to test.
• Ashby is flagged with an open API for the load.
• Lever is cataloged as a fit for: Recruiting CRM plus ATS in one.
• Ashby is cataloged as a fit for: Tech TA teams that want ATS analytics without a BI project.

Phases

1. Export

   Take Lever as the source of truth for this pair. Export pipeline and deal records; synced email and calendar links; workflow rules; saved reports; installed marketplace apps; AI assistant configuration; records for the catalog use cases: ats. CRM-flavored ATS incumbent for talent pipelines.

2. Map

   Load into Ashby only after the field map is written down. Modern ATS with analytics and AI assist — the high-signal Greenhouse alternative. Neither product is flagged for custom objects. Keep the object list short.

3. Prove a sample

   Ashby scores 6/10 on speed to live and 6/10 on migration friendliness. Run one sample load and one report the team already uses in Lever before a full cutover.

4. Cut over

   Lever scores 6/10 on migration friendliness and is marked high difficulty in the catalog. Keep Lever readable until the team is working in Ashby. Lever mixed ATS and recruiting CRM so sourcers could nurture, not just process reqs. It is an incumbent many mid-market teams still run. AI is present; the product is still pipeline plus jobs. Now part of Employ, but still how teams talk about the tool.

Lever to Ashby: what the vendor docs actually cover

Linked sentences come from vendor documentation opened for this page. Everything else is general guidance, not Lever or Ashby vendor documentation. This section does not move data and does not change the catalog outline above.

What to export from Lever

Lever's developer introduction sets the root at api.lever.co version one, JSON over HTTPS, UTF-8. Customer API keys use Basic authentication: the key is the username and the password is empty. The same introduction says integrations, as distinct from a customer's own workflows, use OAuth. Keys live on the Integrations and API page inside Settings, on the API Credentials tab. The Candidates section warns that those endpoints were deprecated as of 2020 and still answer for compatibility. The Opportunities section is the replacement. It defines candidates as people added as potential fits, opportunities as each candidacy or pipeline journey for a job, and a contact as the unique individual who may have several candidacies. One candidate can therefore own many opportunities. Each opportunity carries its own notes, feedback, interview schedules, and forms. The contact id is the stable person id going forward. The older candidate id can be reused as an opportunity id for the pre-migration record, which is a compatibility note, not permission to build on the deprecated routes. An audit event named export:downloaded fires when a company admin uses Export to spreadsheet or downloads something like interview feedback as CSV. Its rows value counts non-header lines. The event proves a download occurred. It does not list the columns. Lever's pricing URL is only a quote. The catalog's custom price matches. A trial length is not written there. The FAQ's SOC 2 Type II line, the vendor's 'weeks, not months' implementation sentence, unlimited transcripts, and VONQ screening are commercial copy. A testimonial on that page is unused.

• Lever API documentation — checked 2026-10-12
• Lever pricing — checked 2026-10-12

How Ashby imports

Ashby, for this Lever pair, still has no platform sticker price on the sheet opened the same day. The sheet's annual line is a ten percent commitment reduction. Extra SMS is priced at ninety dollars per thousand messages across the columns. SSO at one hundred dollars monthly appears on Foundations alone. Headcount bands and the analytics product for companies past one hundred people are printed. CSV intake of candidates, including forwarded resumes, and CSV intake of openings are printed without a visible plan column in the capture. The RPC reference is the same backend-only API described for other Ashby pairs: category.method paths, POST-heavy, JSON, Basic auth, no browser, no CORS. It does not mention Lever opportunities. Manatal's pricing FAQ, read because Manatal is a neighboring ATS and not because it is the destination, accepts CSV or JSON for candidates, jobs, contacts, clients, or departments, and never says Lever. That Manatal sentence is a negative control, not a second destination. The catalog trial flag on Ashby was not confirmed on the sheet.

• Ashby pricing — checked 2026-10-12
• Ashby API reference introduction — checked 2026-10-12

Object and field mapping

• A Lever contact is the person. A Lever opportunity is one candidacy. Ashby's candidate CSV does not say which of those two it expects. Write that choice down before transforming files.
• Notes, feedback, interviews, and forms hang off the opportunity in Lever's docs. They are not described on Ashby's CSV line.
• A Lever posting is the closest concept to an Ashby opening. The openings CSV can include team, location, dates, and compensation. Plan assignment is unknown.
• The deprecated candidate id is not the contact id. Using it as if it were the person key will collide when one person has two opportunities.
• export:downloaded is an audit row, not a mapping file.
• OAuth integrations and Basic API keys are different Lever auth modes. Pick the one the introduction assigns to customer workflows if you are pulling your own data.

What will not carry over

• A named Lever importer inside Ashby.
• Feedback and notes, unless you map them yourself outside these docs.
• The contents of an Export-to-spreadsheet file. The audit event does not describe them.
• Deprecated candidate routes as the long-term model. They remain only for compatibility.
• Lever's implementation-speed sentence. It is the vendor's FAQ, not a schedule for Ashby.
• Manatal as a destination. Its import line does not name Lever, and this pair's destination is Ashby.

Cutover checklist

1. Create a Lever API key on the API Credentials tab if the pull is an internal workflow. Use OAuth only if you are building an integration in the sense the introduction describes.
2. List opportunities, and expand or follow notes, feedback, files, and interviews from the opportunity routes.
3. Store contact id as the person and opportunity id as the candidacy.
4. Do not treat export:downloaded as a schema.
5. Reshape records into Ashby's CSV or call Ashby's RPC from a server.
6. Leave Ashby's CSV plan blank until the column is visible.
7. Quote Ashby SMS and Foundations SSO separately from the missing platform fee.
8. Keep Lever readable through the sample check. Both platform prices are quotes.

Common pitfalls

• Building on Candidates endpoints because they still respond. They were deprecated in 2020.
• Collapsing two opportunities into one person and losing a candidacy.
• Reading the audit row count as a complete backup.
• Quoting Lever's weeks-not-months line as your project plan.
• Calling Ashby's API from the browser.

Related catalog pages

• Best AI-native Lever alternatives (2026) — Which tool, compared
• What should replace Lever? — Switch narrative
• Ashby product page — Modern ATS with analytics and AI assist — the high-signal Greenhouse alternative.
• Ashby vs Lever — Head-to-head already in the catalog
• Recruiting category — Catalog hub for this category