Dayforce Jobs Scraper

Extract public employer job postings from Dayforce career sites locally or on Apify. The Actor uses the anonymous public JobFeeds endpoint for board discovery and the public posting page's structured __NEXT_DATA__ payload for detail enrichment. It does not log in, submit applications, access candidate data, use proxies, CAPTCHAs, or fingerprint spoofing.

Modes

search discovers postings from one or more public board URLs. single fetches one exact /jobs/{postingId} URL. multiple fetches several exact posting URLs. Direct URLs are deduplicated by tenant, career-site code, and posting ID, and maxItems limits complete records.

{
  "mode": "search",
  "startUrls": [
    { "url": "https://jobs.dayforcehcm.com/en-US/lssi/CANDIDATEPORTAL" }
  ],
  "searchText": "Supervisor",
  "maxItems": 3,
  "requestTimeoutSeconds": 15,
  "requestDelayMs": 500,
  "maxRequests": 100
}

Single and multiple examples:

{ "mode": "single", "jobUrls": ["https://jobs.dayforcehcm.com/en-US/lssi/CANDIDATEPORTAL/jobs/1164"] }

{
  "mode": "multiple",
  "jobUrls": [
    "https://jobs.dayforcehcm.com/en-US/lssi/CANDIDATEPORTAL/jobs/1164",
    "https://jobs.dayforcehcm.com/en-US/lssi/CANDIDATEPORTAL/jobs/2769"
  ]
}

Dataset

Complete rows include employer and tenant identity, posting and requisition IDs, title/status/timestamps, evergreen/internal/remote flags, structured locations, job family/function, pay/employment/workplace attributes, salary ranges only when exposed by the feed, full source HTML and plain-text descriptions, separate header/body/footer text and HTML sections, source attributes, feed/site metadata, canonical/detail/listing URLs, source-backed apply URL when present, request receipts, field coverage, and quality metrics. The live LSSI detail page exposes benefits, essential functions, and position qualifications inside the published description; those sections remain source HTML and readable text rather than invented fields. Unavailable optional fields are omitted rather than emitted as nulls, empty arrays, empty strings, or invented placeholders.

Invalid inputs and public request/parser failures are stored in RUN_DIAGNOSTICS with sanitized error text and response receipts rather than mixed into the jobs dataset. OUTPUT, OUTPUT_SUMMARY, and RUN_HEALTH distinguish platform status (SUCCEEDED or FAILED) from dataset resultStatus (COMPLETE, LIMITED, SKIPPED, DEFERRED, NO_DATA, or FAILED). Complete jobs are staged until access classification is settled, then pushed sequentially; counts increase only after pushData() resolves. An explicit source denial discards staged rows and stops requests. Non-block failures after stored rows preserve them as SUCCEEDED / LIMITED; a fatal zero-row failure uses Actor.fail() and FAILED / FAILED. A clean empty result is SUCCEEDED / NO_DATA. HTTP 401/403/429/451 or a visible source-authored CAPTCHA, verification, or denial challenge is SKIPPED; HTTP 407 and no-response transport failures are DEFERRED, not source-block evidence. Diagnostics remain in key-value artifacts. No proxy, stealth, alternate identity, or fingerprint changes are used.

Local development

npm install
npm test
npm run lint
apify validate-schema
apify run --purge --input-file INPUT.json
npm run validate:dataset -- storage

The same bounded input contract works locally and on Apify cloud. Automated tests use mocked requests; current source availability and a newly generated dataset remain unverified until a separately authorized run.