Public ATS job APIs: Greenhouse, Lever, Ashby and SmartRecruiters
A practical guide to four documented public ATS job APIs, with request examples, completeness checks, field preservation and a framework for choosing direct feeds or The Jobs API.
The Jobs API editorial teamPublished · 6 min read
The short answer
Greenhouse, Lever, Ashby and SmartRecruiters document public interfaces for published employer jobs. They are useful for integrating known career boards without parsing page layouts. Each has its own identifiers, response shape and completeness rules. Use direct feeds for a small, verified employer scope; consider The Jobs API when you need searchable Canadian and US inventory across employers with a consistent interface.
What does a public ATS API give you?
An applicant tracking system can expose published vacancies through a structured interface intended for career pages. That interface can be easier to maintain than an HTML selector, but it usually starts with a known employer board. It is not automatically a directory of every employer using the system.
This guide covers four documented read interfaces, checked against official documentation on October 23, 2026. It focuses on published jobs rather than applicant records, private recruiting administration or application submission. The request examples are templates: replace the placeholder with an independently verified board identifier before using one.
Verify the employer relationship from its own careers page. Similar company names and predictable slugs are not enough. Record the original careers URL, the ATS board URL and the date you established that relationship. That small provenance record prevents an integration from quietly importing a different company’s vacancies.
Which public interface should you use?
| ATS | Board identifier | First integration check |
|---|---|---|
| Greenhouse | Verified board token | Request description content explicitly |
| Lever | Verified site name and region | Select JSON and account for pagination |
| Ashby | Verified job board name | Request available compensation and retain all locations |
| SmartRecruiters | Verified company identifier | Paginate listings and retrieve fuller details |
These are four documented options, not a claim that other systems lack public interfaces. Check an employer’s current implementation before deciding which connector applies. A branded careers frontend may use a different backend from the one its appearance suggests.
How do you request Greenhouse jobs with descriptions?
Greenhouse documents unauthenticated GET access to its Job Board API. Add content=true to the board jobs endpoint when you need description content rather than only the shorter list fields. Keep posting IDs distinct from any internal job or requisition IDs returned alongside them.
A normalized job record should not discard fields simply because your first version does not display them. Keep the original response separately from the searchable projection. Verify that the title, location and description in your rendered page match the source before marking the connector ready.
curl --fail --silent --show-error \
"https://boards-api.greenhouse.io/v1/boards/VERIFIED_BOARD_TOKEN/jobs?content=true"How do you retrieve Lever postings as JSON?
Lever documents a postings endpoint under a site name, with skip and limit pagination and a JSON output mode. Its global and EU instances use different hosts; use the one established by the employer’s official board. The global-host template below should not be used to guess an EU tenant’s location.
Keep the complete response when constructing your description. Published content can be split into description text, lists and additional sections. Flattening only a convenient summary field can lose requirements or benefits. Keep hosted and application destinations separate, because they serve different points in the applicant journey.
curl --fail --silent --show-error \
"https://api.lever.co/v0/postings/VERIFIED_SITE?mode=json&skip=0&limit=100"How do you include Ashby compensation data?
Ashby documents a public job-board endpoint with an optional includeCompensation=true parameter. Its response can contain description variants, secondary locations and structured compensation components. Requesting an optional field does not mean every employer supplies a value.
Preserve component type, currency and interval together. A yearly salary, an equity percentage and an unspecified bonus cannot be added into one numeric range. Likewise, keep secondary locations alongside the primary location so a multi-location posting remains intelligible to your users.
curl --fail --silent --show-error \
"https://api.ashbyhq.com/posting-api/job-board/VERIFIED_BOARD_NAME?includeCompensation=true"Why does SmartRecruiters need a list-and-detail workflow?
SmartRecruiters documents company postings with limit and offset parameters. Its guide notes that the list can omit fields and directs consumers to the posting ref for the full object. Use the listed total and pagination metadata to assess completion, then fetch the richer detail for each required posting.
Validate detail destinations against the expected source before following them automatically. Keep list and detail captures separately so you can inspect discrepancies. A list entry that exists while its detail request fails is an incomplete capture, not evidence that the vacancy has closed.
curl --fail --silent --show-error \
"https://api.smartrecruiters.com/v1/companies/VERIFIED_COMPANY/postings?limit=100&offset=0"What must a production connector preserve?
Separate acquisition from normalization. The acquisition record should retain the full response, source URL, fetch time, status and a content hash. The normalized record should contain the fields your application can interpret reliably, with a reference back to that capture. Unknown nested fields remain available for later improvements.
Use a source namespace, verified board identifier and source posting key as the basic identity. Cross-board deduplication is a separate decision that needs evidence; matching titles alone can collapse distinct vacancies. Retain all original locations and preserve missing values rather than inventing a country from an ambiguous city.
Keep HTML source intact in storage while sanitizing it for display. A preserved payload and safe rendering are compatible goals. Do not execute scripts or trust instructions embedded in a description. The job content is evidence, not application configuration.
How do you decide that a scan is complete?
Track the expected pages, received identifiers and required detail captures. A single successful first page is not a complete employer inventory. A rate limit, malformed response or repeated pagination page should mark the run incomplete and retain a resumable checkpoint.
Only use a complete, successful scan as evidence when considering missing postings. Even then, apply a conservative confirmation policy before removing a vacancy. A failed source request, temporary empty page or changed response format should never erase the previous inventory.
Reduce repeated work by comparing meaningful listing changes and reusing fresh details when appropriate. Schedule bounded verification for fields that the listing does not reveal. Respect source pacing and retry instructions; an integration that works once is not yet a reliable refresh process.
When is a unified jobs API the better option?
Direct ATS feeds are a good fit when the employer set is small, verified and stable, and your team can own the adapters. As the scope grows, you also own employer discovery, source changes, completeness monitoring, normalization and lifecycle handling. The HTTP request is only a small part of that work.
The Jobs API provides one documented interface for Canadian and US job products, with search, full descriptions and lifecycle endpoints. It is worth evaluating when cross-employer inventory is the product requirement and maintaining source adapters would distract from the customer experience.
Compare a real workload rather than an abstract build-versus-buy argument. List the required employers, available engineering time and monthly retrieval volume. Test our trial against that list. If a small direct integration already meets the requirement, keep its simplicity; if maintaining many sources dominates your roadmap, evaluate the managed interface.
Questions people ask
Are these public ATS APIs complete directories of all employers?
No. These interfaces use a known board, site or company identifier. Employer discovery and verification remain separate work.
Does a 200 response prove that all jobs were collected?
No. You must check pagination, expected totals where available and required detail requests. A partial successful response can still leave most of a board uncollected.
Should missing salary or location values be inferred?
Not as source facts. Preserve missing values and all original evidence. Keep any explicitly derived enrichment separate from employer-supplied fields.
When should I choose The Jobs API instead of direct ATS integrations?
Consider it when you need a consistent searchable Canadian and US inventory across employers and want to reduce the number of source adapters your team maintains. Verify required coverage with a bounded trial.