Greenhouse, Lever and Ashby Compared for Data Users

Job postings are one of the few public signals a private company emits every week. Most of those postings do not live on the careers page you see. They live in an applicant tracking system, an ATS, that renders the page and exposes the underlying data. Three ATS vendors dominate the startup and growth segment: Greenhouse, Lever and Ashby. All three offer public JSON endpoints. All three are free to read. No API key is needed for the public job board data.

That is where the similarities end. Each system publishes a different set of fields. Each omits different things. And each uses a date field that means something different. If you treat the three as interchangeable, your "new job posted" signal will be wrong in quiet but systematic ways. This piece compares them from the perspective of someone building a dataset, not someone applying for a job.

Why these three matter

When a startup raises money, hiring usually follows. The raise itself often shows up in a Form D filing with the SEC, and we cover how to read one in how to read a Form D filing. The hiring shows up on a job board. The job board runs on an ATS. Greenhouse and Lever have been the default choices for venture-backed companies for over a decade. Ashby is the newer entrant and has been winning startups in recent years. Between them, they host the public job data of a large share of the private companies that matter to anyone tracking startup activity.

The appeal for data users is timeliness. Official labor statistics, like the job openings series that the Bureau of Labor Statistics publishes in its JOLTS program, are aggregated and arrive with a lag of weeks. A posting on an ATS board appears the day the company publishes it. Compared to investor disclosures the gap is even wider. A 13F portfolio snapshot can be 45 days old on arrival, as explained in 13F deadlines and the 45-day lag. A job board tells you what a company wants right now.

Greenhouse: rich structure, ambiguous dates

Greenhouse exposes a public Job Board API. For any company you can request the list of open jobs on its board and, with a flag, the full description content. What you get is well structured. Each job has a stable numeric id, a title, a location string, an absolute URL, and links to departments and offices. Departments and offices are first-class objects with their own ids. That makes Greenhouse the easiest of the three for building team-level hiring breakdowns.

What Greenhouse omits is also clear. There is no structured salary field in the public board data. Pay ranges, where they appear, are embedded in the description text because state laws require them. There is no employment type field and no remote flag. If you want to know whether a role is remote, you parse the location string and the description. The metadata field exists for custom attributes but is empty on most boards.

The date situation needs care. Every Greenhouse job carries an updated_at timestamp. It changes whenever anything about the posting changes. A recruiter fixing a typo resets it. Treating updated_at as a posting date will make old roles look new. Greenhouse also exposes a first published timestamp on board API responses, which is the field you actually want for posting age. Use the published field for age and updated_at only for change detection.

Lever: one date, taken at creation

Lever's public postings endpoint returns all published postings for a site in one response. The structure is flatter than Greenhouse. Categories carry the team, department, location and commitment, where commitment is a string like full time. Lever also publishes a workplace type field that marks a posting as on-site, remote or hybrid. That is a genuine advantage. It is a structured answer to the remote question that Greenhouse makes you infer.

The description arrives as HTML plus a set of lists, which are the bullet sections of the posting. Like Greenhouse, Lever's public data has no reliable structured compensation field. Pay ranges live in the text when they appear at all.

Lever's date field is createdAt, an epoch timestamp in milliseconds. Note the name. It records when the posting was created in the system, not when it went live. A company can draft a role, sit on it for weeks, then publish. The posting will look weeks old the moment it appears. In practice most companies publish quickly after creating, so createdAt is a usable proxy for posting date. But it is a proxy. It leans early. And there is no update timestamp at all in the public data, so you cannot tell whether a posting was edited after launch.

Ashby: the most honest fields, behind opt-ins

Ashby's posting API returns a job board by name, with jobs that carry title, department, team, location, secondary locations, employment type, a remote flag and a publishedAt timestamp. Two things stand out.

First, publishedAt is what it says. It marks when the posting went public. Of the three systems, Ashby is the only one whose primary date field directly answers the question data users actually ask.

Second, Ashby can publish structured compensation. When a company enables it, postings carry salary ranges as data, not as a sentence buried in the description. This is the cleanest compensation data available from any of the three. The catch is the opt-in. Coverage depends on company settings, so a pipeline cannot assume the field is present.

Ashby's omissions mirror its strengths. Only listed jobs appear. Confidential and unlisted roles are simply absent, with no marker that anything is hidden. The same is true on the other two platforms, but it is worth stating once: an ATS board shows you what the company chose to show.

The shared blind spots

Some gaps are common to all three, and they matter more than any single field.

Closed roles vanish. When a job is filled or cancelled, it disappears from the feed without a tombstone. There is no history endpoint. If you were not polling, the posting never existed as far as you can tell. Any serious dataset has to snapshot boards on a schedule and diff them, because the platforms will not do it for you.

Openings are invisible. One posting can back one hire or twenty. None of the three public APIs tells you how many seats sit behind a listing. A "Software Engineer" posting that stays open for a year may be evergreen pipeline building, not a single unfilled seat.

Repostings look like new jobs on two of the three. A closed and relaunched role gets a fresh record. Only careful matching on title, team and location catches it.

None of this makes the data bad. It makes the data shaped. Public companies must describe their human capital resources in annual reports under the SEC's 2020 human capital disclosure rule, which gives you an official anchor to check job board inferences against for listed firms. Private companies offer no such anchor. For them, the ATS feed and the Form D trail are often all you have.

How the date fields line up

If you normalize across the three, map everything to a single "first seen public" date, prefer the platform's publish field where it exists, and let your own snapshot diffs act as the fallback clock. Your polling history is the one date source that means the same thing on every platform.

Hiring data works best as a companion signal, not a standalone one. A cluster of new engineering postings after a fresh capital raise tells a coherent story. The same cluster in isolation tells you much less. Nothing here is investment advice.

If you want the other half of that story, the capital raises themselves, we track new Form D filings and score them daily. See the Startup Capital Raises Form D report for the companies that just raised and are about to show up on these job boards.

Want the signal instead of the raw filings? Get a free report preview. Prefer the tool to the write-up? Browse all data feeds or connect the free MCP server.