Four-Day Week Jobs Scraper

Extract complete public reduced-hours job records from the official, no-auth 4dayweek.io v2 jobs API. The default schedule=4_day_week filter is source-provided evidence that the role belongs to the site's four-day-week collection.

Input

Field	Default	Description
query	""	Optional full-text role, skill, or company query.
category	""	Optional category slug or comma-separated slugs.
schedule	4_day_week	Source schedule slug or comma-separated slugs.
workArrangement	""	Optional remote, hybrid, onsite, or comma-separated values.
country	""	Optional country filter.
maxItems	25	Maximum complete public API records, from 1 to 500.
maxPages	10	Pagination safety cap, from 1 to 50.

{
  "query": "",
  "schedule": "4_day_week",
  "workArrangement": "remote",
  "maxItems": 25,
  "maxPages": 10
}

Output

Each item is built from a complete public API record and contains the title, employer, public employer profile, structured locations, schedule and weekly-hour bounds, work arrangement, salary when published, categories, role/level, contract type, skills, tools, markdown description with sections and readable text, requirements/responsibilities/benefits where headings expose them, dates, search filters, and canonical job URL. Source request receipts and run diagnostics are kept in KVS rather than duplicated in new dataset rows. Source fields that are absent are omitted. Records contain more than 20 populated meaningful fields.

Chrome comparison showed that a fresh public detail page can expose title, hours, schedule, location, and a short role/company description while gating the company identity, full description, requirements, benefits, and application link behind the site's Pro subscription. The API does not publish an employer application URL, so application.available and application.urlPublished are false and no applyUrl is fabricated.

The actor writes OUTPUT_SUMMARY, REQUEST_RECEIPTS, RUN_DIAGNOSTICS, RUN_HEALTH, and OUTPUT to the default key-value store. OUTPUT.status is platform state (SUCCEEDED or FAILED); OUTPUT.resultStatus is data disposition (COMPLETE, LIMITED, SKIPPED, DEFERRED, NO_DATA, or FAILED). Complete records already stored remain SUCCEEDED / LIMITED if a later write or finalization step fails. Diagnostics and dummy rows are never pushed to the dataset. Raw API objects and contact details are not emitted; contact-like text in public descriptions is redacted.

Access policy

Requests use ordinary direct HTTPS with fixed timeouts, no proxy, no stealth or fingerprint changes, no alternate identity, and no retries. An explicit HTTP 401/403/429/451 response or human-verification/access-denial challenge stops the run, discards buffered rows, and reports SUCCEEDED / SKIPPED; HTTP 407, redirects, invalid JSON, or another unverified source/transport response is DEFERRED. A clean empty API response is NO_DATA; a fatal zero-row error is FAILED / FAILED. Rows gathered before a generic later failure may be stored as genuine jobs and reported SUCCEEDED / LIMITED.