Job Boards Scraper — four boards, one schema

RemoteOK, Arbeitnow, The Muse and WeWorkRemotely in a single unified output. Filter across all four at once instead of writing four adapters.

Sample output

{
  "id": "arbeitnow:member-of-technical-staff-research-engineer",
  "source": "arbeitnow",
  "board": "arbeitnow",
  "company": "blackforestlabs",
  "title": "Member of Technical Staff - Research Engineer",
  "location": "San Francisco (USA)",
  "remote": false,
  "department": null,
  "employmentType": "Full Time",
  "postedAt": "2026-08-02T23:56:25.000Z",
  "applyUrl": "https://www.arbeitnow.com/jobs/companies/blackforestlabs/…",
  "descriptionText": "We are looking for a research engineer to…",
  "tags": ["ai", "research"],
  "attribution": null
}

Every row carries these 14 fields and no others. There is no salaryText and no updatedAt: none of the four boards publishes a salary any more (RemoteOK still has the field but returns 0/0 on every row), and none publishes a modification timestamp. Rather than ship two permanently-null columns, they are not emitted. descriptionText is plain text — entity-encoded markup is decoded and stripped, so you never receive <p> or a live <p> tag.

Why this one

• One schema across four boards. company means company everywhere. Most tools return each board's native field names and leave the normalising to you.
• Same shape as our ATS Jobs Scraper. Run both and union the datasets — no adapter, no field mapping. Together they cover public boards and company applicant tracking systems.
• Filter before you pay. Keywords, location, remote and date filters are applied before rows are billed.
• Depth when you want it. The Muse alone exposes 400,000+ jobs across 20,000+ pages. maxPagesPerSource controls how deep you go.
• Attribution passed through. Where a source supplies attribution text with its data, it is carried in the attribution field rather than dropped.

Input

Field	What it does
sources	Which boards. Defaults to all four.
keywords	Match in title, company, tags or description.
locations / remoteOnly / postedAfter	Standard filters.
maxPagesPerSource	Depth per board. Default 3.

{ "keywords": ["engineer", "developer"], "remoteOnly": true, "maxPagesPerSource": 5 }

Reliability

Every run writes RUN_STATS with per-source page outcomes — ok, empty, drift, transport, rate_limited — plus the sources that answered and the ones that did not, by name.

A blocked source is never reported as a quiet one. A source that fails to respond is counted as transport or rate_limited, never as empty, and the failing source is named in the log. If one source is down the run still succeeds with the other three, because partial coverage is resilience. If every source fails, the run fails — you get a red run and an explanation instead of a green run and an empty dataset.

drift means a source returned records but our parser produced none. That is our bug, not your empty week, and it is reported as such.

When a run legitimately matches nothing — a narrow keyword, remoteOnly, a tight postedAfter — the dataset gets a single unbilled receipt row instead of being left empty:

{ "type": "no_changes", "sourcesChecked": 4, "sourcesAttempted": 4, "jobsSeen": 635, "checkedAt": "2026-08-05T12:11:02.476Z" }

Job rows never carry a type field, so your pipeline can branch on it.

Pricing

Pay per job returned. Filtered-out jobs and failed pages cost nothing.