Reed.co.uk Jobs Scraper

Scrapes job vacancies with full descriptions from Reed.co.uk — one of the UK's largest job boards, with over 100,000 live vacancies at any time.

Public data only. No login, no API key, no browser. This reads the same public pages Reed's own website renders — it is not the key-gated partner API.

What you get

Two record types share one dataset, told apart by recordType.

JOB — one row per vacancy

Search rows carry title, employer, salary range, location, job type, posting date and a description snippet. With Fetch full job descriptions on (the default), each row also gets a jobDetails object:

• the complete job description (HTML as the employer wrote it)
• salary breakdown, contract type, part/full-time flags
• created / display / expiry dates
• application method (easy-apply vs external), eligibility notes
• recruiter and employer identifiers

SEARCH_SUMMARY — one row per keyword

Upstream's match total, how deep the run paged, and exactly which filters were sent.

Input

Field	What it does
Search keywords	one search per entry, each with its own summary row
Location	town, city, county or postcode — applies to every keyword
Distance from location	radius in miles (needs a location)
Salary from / to	annual salary range
Posted within	today, last 3 days, or last week
Job type toggles	full-time, part-time, contract, temporary, graduate, agency
Job URLs	scrape specific vacancies directly, skipping search
Max jobs per keyword	0 = unlimited, and Reed has no page ceiling
Fetch full job descriptions	off = fast listing-only crawl, 1 request per 25 jobs

Example

{
  "keywords": ["python developer", "data engineer"],
  "location": "London",
  "salaryFrom": 50000,
  "datePosted": "lastweek",
  "maxItems": 500,
  "includeJobDetails": true
}

Three things this actor is honest about

1. It only offers filters that actually work. Reed answers an unrecognised filter with HTTP 200 and the unfiltered result set — no error. Every option here was verified to genuinely move the match count, and the ones that don't were left out on purpose:

• permanent looks like a real filter and isn't — it returns the exact unfiltered baseline, so it is not offered.
• Only today, last 3 days and last week are honoured for date. "Last month" and "yesterday" are silently ignored by Reed, so they are not offered and an unknown value is refused before the run starts.

2. Reed has no working sort. sortby was tested with six different values including a deliberately bogus one — all returned the identical results. Rather than ship a knob that does nothing, this actor offers no sort and reports sortSupported: false on every summary row.

3. Expired jobs are reported, not crashed on. Reed returns HTTP 410 Gone (not 404) for a filled or expired ad. Those become a clean _error: "gone" row, or a _detailError note on an otherwise good search row — one job expiring mid-crawl never costs you the other 99.

Notes on reliability

• No pagination ceiling. Unlike most portals, Reed serves rows at pageno=4036 on a 100,000-match query. maxItems: 0 really does mean everything — set a bound unless you mean it.
• No WAF challenge. Cloudflare is in the path but passive; data comes back cold on every TLS profile tested.
• Runs unattended. No human-captured session, no expiring token.
• Residential proxy by default on cloud runs.

Output envelope

Every record carries _input, _source and _scrapedAt. Upstream field names pass through verbatim — no renaming. _source is S1-nextdata-search for listing-only rows and S1-nextdata-search+S2-nextdata-jobdetail once descriptions are attached.

Note the search row's own fields sit under jobDetail (singular, upstream's naming); the fuller detail-page payload is jobDetails (plural).

See CRAWLING_METHOD.md for the full reverse-engineering trail, including the per-filter verification table and the 410 finding.