Job Postings API for Consultants: Read the Board

Consultants read job postings for what they say about a company rather than for the jobs. A target that claims it is moving upmarket should be hiring enterprise account executives. A client's three closest rivals all opening data-engineering roles in the same quarter is a slide. An org-design engagement starts with how peers title and locate the same function.

The vendors that rank for job data sell feeds aggregated across thousands of employers, which suits a labour-market study. A job postings api for consultants usually has a narrower job: these twelve named companies, what they are hiring for, where, and since when. For that question the data already exists, published by each company, as JSON.

Where are a company's job postings, as data?

On the company's applicant tracking system. A great many careers pages, especially at venture-backed companies, are a front end for Greenhouse, Lever or Ashby, and all three serve a public, unauthenticated job-board API:

The {token} is in the careers page's links. One scrape with the links format costs 2 credits; look for job-boards.greenhouse.io/, jobs.lever.co/ or jobs.ashbyhq.com/ followed by a name. That name is the token. A company on Workday or a home-built page has no such endpoint, and its careers page is read with scrape like any other page.

What does one call return?

The board, unprocessed. fetch_url costs 1 credit and puts the response body in content:

curl -X POST https://crawlforge.dev/api/v1/tools/fetch_url \
  -H "X-API-Key: cf_live_NORTHWIND_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://boards-api.greenhouse.io/v1/boards/rival-a/departments",
    "max_inline_chars": 1000000
  }'

Raise max_inline_chars, because boards are bigger than they look. A 665-role Greenhouse board came back at about 480 KB through /departments, well past the 40,000-character default. Under the default you get a preview and a result_handle instead, and the rest is read with read_result for 1 credit. Lever and Ashby include each role's full description, so a large board runs to megabytes; Lever takes limit and skip to page it.

What makes this better than a scraped careers page is the date. first_published tells you a sales role has been open since last December, and a requisition open ten months says something different from one posted this week.

How do you compare a peer set over time?

Snapshot it on a schedule and diff by job id. New ids are new requisitions; ids that disappear were filled or pulled. Twelve peers cost 12 credits a snapshot, so a weekly snapshot across a 13-week engagement is 156 credits. Run it with a key named after the client and the spend sits in the request log under that name.

If the evidence lives on a rendered careers page rather than a board, a monitor per client watches it for you. When the hiring question is part of diligence, testing a target's growth story against its own open roles, the due diligence post covers where that fits.

What won't it do?

• No aggregated feed. It searches no job sites and builds no cross-employer index. Market-wide salary or demand studies need a data vendor.
• No history before your first snapshot. A board shows what is open now. The archive is the snapshots you keep.
• No normalisation. Titles, departments and locations arrive as each company wrote them; mapping "AE, Mid-Market" to a common taxonomy is your work.
• No people. It returns roles, not hiring managers or contact details.
• robots.txt is respected by default. A disallowed URL is refused before anything is fetched and costs nothing.

Start free with 1,000 credits. That is one-time and covers a twelve-company snapshot every week for well over a year. After that a 1K pack is $3. The fetch_url reference has every parameter.