Ashby Jobs Scraper: Startup Job Boards → JSON

Give it an Ashby board slug, a board URL, or a company: get every live job on that startup's Ashby board as clean, normalized JSON, including the employer's own published salary ranges, in seconds, straight from Ashby. Not from an index that was built a few hours ago: this Actor reads the employer's own Ashby posting API at the moment you ask, so what you get back is what a candidate would see on the careers page right now.

• What you put in: one or more Ashby boards. The fastest path is the board slug: the jobs.ashbyhq.com/{slug} identifier, but you can also paste a board URL or a company name and let the Actor resolve it.
• What you get back: one record per live job posting, in a single canonical schema, plus one status record per board telling you exactly what happened: found, no_board, or error.
• The native-salary edge: Ashby serves structured compensation, so when an employer publishes pay, this Actor returns it as the employer stated it: salary.source: "stated", not a re-parsed estimate.
• Boosted by the Apify platform: full REST API access, scheduling, monitoring, webhooks and integrations, datacenter proxy rotation, and dataset export to JSON, CSV, or Excel.

What is the Ashby Jobs Scraper and what can it do?

The Ashby Jobs Scraper is a live Ashby job board API: you name a board and it returns every open role on it as structured JSON. Ashby is the applicant tracking system the startup world runs on: Notion, Ramp, Linear, PostHog, OpenAI, LangChain, Deel, and Vanta all post through it, so this is the tool you want when you care about startup hiring specifically, or about the accounts and portfolio companies whose Ashby boards you already know.

It reads Ashby through its official, public, no-authentication JSON API: the most stable class of source that exists for jobs data, and the reason this Actor needs no browser, no residential proxy, and no anti-bot workarounds. It is Ashby-focused on purpose: a narrow, testable promise beats a broad, flaky one. If you need Greenhouse, Lever, or Workable too, or you do not know which system a company uses, the Job Postings API flagship resolves the board for you across all four.

Live vs. indexed: why freshness and native salary are the whole point:

What it deliberately does not do: it does not search across companies by keyword, it does not maintain an index or a history, it does not fetch per-posting application questions (Ashby has no public per-posting endpoint, and the whole board already carries full descriptions), and it does not normalize salary to USD or invent one with AI. Inferred fields are exactly where indexed competitors accumulate quiet errors. This Actor's promise is narrower and honest: the live board, with the employer's own salary, correctly normalized.

What data does it extract? (output fields)

Every record is a canonical JobPosting: a stable id, the source (ashby) and its native id, the posting URL, raw and normalized titles, company, structured location, department, description in HTML and plain text, and the dates the role was posted and observed.

Two things are worth calling out:

• salary is Ashby's differentiator. When an employer opts to display compensation, the native range is returned with source: "stated": the widest published salary band, in the employer's own currency and period, with equity kept separate rather than folded in. When a board does not publish pay, a figure is read out of the description if the employer states one (source: "parsed"), and when pay cannot be established honestly the field is simply absent: never guessed. Native salary is mapped even if you switch descriptions off in the output.
• Ashby-specific fields that do not fit the canonical schema: the raw compensation tiers (all tiers plus equity), secondaryLocations, team, isListed, and shouldDisplayCompensationOnJobPostings, are preserved under extras.ashby rather than dropped or forced into a field where they do not belong.

Alongside the job records, each input board produces one board-status row:

{ board, company?, jobCount, status }

How to use the Ashby Jobs Scraper (tutorial)

1. Click Start with the example input already filled in: one board, no options.
2. Watch the run finish (a single board typically completes in a few seconds).
3. Open the Dataset tab. You will see the job records plus one board-status row.
4. Export as JSON, CSV, or Excel, or call the run from your own code through the Apify API.

To run it on your own boards, replace the boards array. Each entry needs one of slug, boardUrl, or company:

• slug: the jobs.ashbyhq.com/{slug} identifier, e.g. Ramp. This is the fastest, zero-guess path. (Ashby slugs are case-insensitive.)
• boardUrl: a board URL to parse the slug from; both the board form jobs.ashbyhq.com/{slug} and a job-detail link jobs.ashbyhq.com/{slug}/{jobId} are understood.
• company: a company name or slug; the Actor tries it directly as a slug, and, when it looks like a domain, reads that company's careers page for an Ashby link (with a similarity guard so it never resolves the wrong board).

Boards in a batch are processed one after another, at a deliberately polite request rate to Ashby. If you are polling on a schedule, prefer several small runs over one very large one.

How much does it cost to scrape Ashby?

Pay-per-event, with two events:

• $0.002 per board processed: charged once per board that reached a definitive answer, whether that answer is "here are the jobs" or "there is no such Ashby board". The resolve-and-fetch work has value either way. This is lower than the flagship's fixed fee because there is no cross-ATS detection: one fetch, no pagination.
• $0.001 per job posting returned: charged per validated record ($1 per 1,000 jobs).

Failed lookups are free. A board whose status is error is never charged, and neither are the records of a board whose fetch failed part-way through: they are discarded rather than delivered. We charge for answers, not for our own failures.

A worked example: 10 boards averaging 60 open roles each costs 10 × $0.002 + 600 × $0.001 = $0.62. The comparable live-side APIs charge $1.20–$1.50 per 1,000 jobs; this undercuts them on the marginal price while shipping the employer's native salary they parse or normalize away. Platform usage costs are absorbed, not passed through.

Input and output examples

Input: the simplest useful run (Ramp: 126 live roles, all with native compensation):

{ "boards": [{ "company": "Ramp" }] }

Input: a filtered batch by slug and URL:

{
  "boards": [
    { "slug": "Ramp" },
    { "boardUrl": "https://jobs.ashbyhq.com/linear" }
  ],
  "titleFilter": "engineer",
  "remoteOnly": true,
  "maxJobsPerBoard": 25
}

Output: one job record (trimmed) with a native salary, and its board's status row:

{
  "id": "9a1f…",
  "source": "ashby",
  "url": "https://jobs.ashbyhq.com/ramp/a1b2c3",
  "title": "Senior Platform Engineer",
  "titleNormalized": "Senior Platform Engineer",
  "company": { "name": "Ramp", "sourceSlug": "ramp" },
  "location": { "raw": "San Francisco, CA", "city": "San Francisco", "remote": "unknown" },
  "department": "Engineering",
  "salary": { "min": 211400, "max": 290600, "currency": "USD", "period": "year", "source": "stated" },
  "extras": { "ashby": { "team": "Platform", "shouldDisplayCompensationOnJobPostings": true } }
}

{ "type": "board-status", "board": "ramp", "company": "Ramp", "jobCount": 126, "status": "found" }

titleFilter, departmentFilter, and locationFilter are plain, case-insensitive substring matches, not regular expressions. departmentFilter matches an Ashby role's department or its team. remoteOnly keeps every role that is not clearly on-site, so a role whose posture cannot be determined is kept rather than silently dropped.

Other Actors you might need

If your list spans several applicant tracking systems, start with the flagship: resolving the board is the part it does for you.

FAQ, legality, and support

How do I find a company's Ashby board slug?

The slug is the identifier in the board URL. If a company's careers page links to jobs.ashbyhq.com/ramp, the slug is ramp. You can paste that slug, paste the whole URL, or just give the company name and let the Actor resolve it. Ashby slugs are case-insensitive, so Ramp and ramp reach the same board.

Does it return salary?

Yes, and this is the reason to use it. Ashby serves structured compensation, so when an employer publishes pay, the record carries the native range with source: "stated" in the employer's own currency and period. When a board does not publish pay, a stated figure in the description is read out as source: "parsed"; when none can be established honestly, salary is absent rather than guessed. Equity is preserved raw in extras.ashby and never counted as base salary.

How is this different from an indexed jobs API?

An indexed API crawls many career sites on its own schedule and serves you a copy, usually with a parsed-or-normalized salary. That is the right shape for "show me every engineering job posted this week", and the wrong shape for "what is on this board right now": the copy is only as fresh as the last crawl, and the salary is an estimate. This Actor holds no index. It reads the board when you ask and returns the employer's own numbers.

Can I scrape multiple companies' Ashby boards at once?

Yes. Put several entries in the boards array: up to 500 per run, mixing slugs, URLs, and company names freely. They are processed one after another at a polite request rate, and each gets its own board-status row.

What if a board does not exist?

You get a board-status row with status: "no_board", and the run still succeeds. "There is no such Ashby board" is a genuine, useful answer, and it is priced as one processed board with no job results.

What happens when Ashby changes its API?

Every response is shape-checked before it is normalized. A change that breaks the shape fails the affected board loudly instead of emitting silently wrong records, and a scheduled smoke test runs against known-stable boards so we usually find out before you do.

Is this legal to use?

The data is public, employer-published job advertising, retrieved through Ashby's own public posting API. Job postings are not personal data, attribution and apply URLs are preserved on every record, and native compensation is employer-published and intentionally public. As always, how you use the data is your responsibility.