Most job boards have to be read from their HTML. Get on Board is the exception in this cluster: it publishes an OpenAPI description of its own API, and the public half of that API returns the same jobs and companies a visitor sees. The interesting part is not whether it can be read but what the numbers it returns actually mean.
A public API, documented
The OpenAPI file at getonbrd.com/doc/openapi.yaml describes two faces. The public API is, in its own words, open to anyone, serving the data visible on the platform without logging in, with no authentication required: categories, company profiles, published jobs and a job search endpoint. The private API carries company accounts, applications and candidates, and needs a subscription.
The Get on Board Jobs Scraper reads the public half only. A URL guard in the code makes the private job endpoint, which answers 401, unreachable — the boundary is a property of the code rather than a line in a README. robots.txt is no constraint here either way: fetched on 10 October 2026, getonbrd.com/robots.txt was a single comment pointing at robotstxt.org, with no rules. Get on Board's Terms of Service, read the same day, are written for company accounts and subscriptions, and a search of them for scraping, crawling or robots found no clause on the subject.
The same public API serves companies. With outputType: companies the Actor returns one row per company hiring within the filters — 228 companies had open jobs on 23 September 2026 — with its open job count, titles, categories, remote job count, jobs with a salary, and the salary range across its jobs. Setting companySource: directory lists every company profile on the board instead, about 17,000 of them, without job aggregates, because most of the directory is not hiring at any given moment.
How it pages, and two traps
The Actor's research on 23 September 2026 measured the API's paging directly, and two behaviours would quietly corrupt a naive crawler.
| Request | What came back |
|---|---|
per_page = 121, 200 or 1000 | 120 rows, no error: the cap is silent |
page = 0, -1 or abc | Page 1 again, which repeats data |
Page past the end | HTTP 200 with an empty data array |
search with an empty query | Empty result; with no query parameter at all, HTTP 422 |
jobs/{id} | HTTP 401: private, never requested |
The stop rule therefore cannot be “until an error”. The Actor stops on an empty page, a page with no new ids, the declared page total, or a short page — whichever comes first. A search cannot be empty, which is why a run with no query and no category walks the categories instead to return the whole board: 934 jobs across 18 categories that day, in about 20 API pages.
The salary is a conversion
The API returns a salary range on 41.2% of the 934 jobs — 54.5% of jobs from non-Chilean companies, 37.1% from Chilean ones, 52.4% of remote jobs. Those rates are a census of the board on the day, not a sample. What the API does not say is the unit.
Comparing 14 salaried job pages against the API showed that every API salary is the posted figure converted to gross USD per month and rounded to 100. A job posted at USD 85,000 to 115,000 a year arrives as 7,100 to 9,600. Nothing in the API response marks it as converted, which is why the Actor names the fields salary_min_usd_month and salary_max_usd_month and adds yearly equivalents, rather than inheriting a field name that would invite someone to treat a monthly figure as annual.
What the job page adds
includeJobDetails reads each job's public page as well, at one extra request and one extra event per job. It was measured on 24 pages:
- The salary exactly as posted, with period and currency, on 14 of 14 salaried pages — the fields that tell a yearly offer from a monthly one.
- Where remote candidates must live, as written, on 8 of 24 pages, against 0 of 24 in the API's own field for it.
- The last time the company reviewed applications, on 24 of 24.
- An equity flag, which appeared on 1 of 24.
The cost multiplier is the reason it is optional: the listing returns up to 120 jobs per request and the job page is one request per job.
{
"searchQueries": ["react"],
"remoteOnly": true,
"seniority": ["senior", "expert"],
"withSalaryOnly": true,
"includeJobDetails": true,
"maxResults": 200
}Bursts, not volume
Fifteen sequential requests and thirty in bursts of about six all returned 200. Forty concurrent requests at 46.3 per second returned 20 as HTTP 429, with no retry-after header, and the next request after the 429 already succeeded. That is a burst limit, not a volume quota, so the listing is read in series and job pages default to three in parallel. On Apify, 31 runs needed no proxy and recorded 0 retries.
Get on Board is one of five sources in this cluster, and the only one that publishes an invitation to be read — how the five compare. Contrast it with a source whose structure is a convention rather than an API: Hacker News Who is Hiring.
Cost of the whole board
A job row is $0.00045 and a company row $0.0009. The whole board, about 1,000 jobs, costs about $0.45 per pull; with job-page details on every job it is about $2.45. Error rows, including a search that matches nothing, are never charged — the run ends green with an explanation row instead of an empty dataset.
Company rows are $0.0009 each, so the 228 companies hiring on 23 September 2026 would cost about $0.21. Duplicates are never delivered twice within a run: a job matched by two queries, or by a query and a category, is one row and one charge.