Workday Jobs Scraper — Any myworkdayjobs.com Career Site

For talent-intelligence, sourcing, and job-aggregation teams that need job postings from companies hosted on Workday — one of the largest ATS/HCM platforms, used by thousands of enterprises for their careers pages (myworkdayjobs.com).

Pay per result — from $1.50 / 1,000 jobs. No API key, no browser, no proxy. Uses Workday's own CXS (Candidate Experience Service) JSON API — the same API the career-page website itself calls in the browser.

How it works — access path

Paste a company's Workday career-site URL (the URL you see when you visit their careers page, e.g. https://nike.wd1.myworkdayjobs.com/NikeCareers), and the actor:

1. Extracts tenant (nike), wdServer (wd1), and site (NikeCareers) from the URL.
2. POSTs to https://<tenant>.<wdServer>.myworkdayjobs.com/wday/cxs/<tenant>/<site>/jobs with {"appliedFacets": {}, "limit": N, "offset": N, "searchText": ""} and paginates via offset/limit until the listing is exhausted.
3. Optionally (includeDescriptions=true, default) GETs the per-job detail endpoint .../wday/cxs/<tenant>/<site>/job/<externalPath> for each posting to fill in the full description, requisition id, remote type, and employment type — fields the listing call doesn't include.

This CXS URL/JSON pattern is structurally the same across every Workday tenant — it isn't a per-company scrape, it's one integration that works for any myworkdayjobs.com site. Requests use Chrome TLS impersonation (curl_cffi) since Workday fronts many tenants with bot-management that blocks plain HTTP clients.

Input

{
  "siteUrls": ["https://workday.wd5.myworkdayjobs.com/Workday"],
  "titleKeyword": "engineer",
  "locationKeyword": "Remote",
  "remoteOnly": false,
  "includeDescriptions": true,
  "maxJobsPerSite": 50,
  "maxTotalJobs": 0
}

How to find a site URL: open the company's careers page — if it's on Workday, the address bar will show something.wdN.myworkdayjobs.com/SiteSlug. Paste that whole URL as-is.

Output schema

Field	Description
company	Workday tenant slug (e.g. nike)
title	Job title
location	Primary location
all_locations	Primary + additional locations, comma-joined
remote_type	remote / hybrid / onsite / null
seniority	executive/vp/director/manager/principal/staff/lead/senior/mid/entry/intern, inferred from title
employment_type	Workday timeType (e.g. "Full time") — only populated with includeDescriptions=true
posted_at_raw	Workday's own posted-date text, verbatim
posted_at_is_exact	true if posted_at_raw parses as a real ISO date, false if it's a relative string like "Posted Today"
job_id	Requisition id (jobReqId, e.g. JR-0097159)
external_path	Workday's internal per-job path (stable across runs — usable as a dedup key)
url	Public apply/posting URL
apply_url	Same as url on this platform
description_text / description_html	Full job description — only populated with includeDescriptions=true
global_id	workday:<tenant>:<site>:<jobId or externalPath> — stable dedup key
parse_confidence	0.0–1.0 quality score
warnings	Machine-readable parse-quality flags

Known limitations (honest)

• postedOn is often a relative human string, not an exact date (e.g. "Posted Today", "Posted 30+ Days Ago"). This is a real Workday platform limitation, not a parsing bug — most tenants do not expose an exact ISO timestamp via CXS. posted_at_raw carries whatever Workday returns verbatim; posted_at_is_exact tells you whether it happens to be a real date on that tenant.
• Salary and department are intentionally NOT in the schema. Workday's CXS API does not reliably expose either across tenants — rather than ship a column that's almost always null, they're omitted.
• Field names and exact response shape were confirmed via multiple independent research sources (Workday integration write-ups, an open-source Workday job crawler's documented output schema, and third-party API-reference pages) that converge on the same jobPostings / jobPostingInfo structure and the /wday/cxs/<tenant>/<site>/jobs + /job/<externalPath> endpoint pair. This was not verified against a live tenant response during development (research/build session ran without hitting the live target from an unproxied connection, per this fleet's access policy) — the parser is written defensively (multiple fallback field names, graceful degradation to listing-only fields) to tolerate the minor per-tenant/per-CXS-version field variation these sources note, but a first production run should be spot-checked against a couple of real tenants before scaling up.
• Some tenants require additional facet parameters (e.g. a locations or jobFamilyGroup applied facet) to see certain job families in the default unfiltered search — this actor sends an empty appliedFacets object, which returns the full unfiltered job list on the tenants this was researched against, but an unusual tenant configuration could in principle require a facet to be pre-selected. Not observed in research, flagged for completeness.
• Very large tenants (thousands of open reqs) with includeDescriptions=true make one extra HTTP request per job — expect proportionally longer/costlier runs; set includeDescriptions=false for a fast metadata-only pass.

Wedge vs. generic Workday scrapers

Most Workday scrapers on the market return raw CXS fields as-is. This actor adds: canonical seniority and remote_type classification, a stable global_id dedup key independent of Workday's own (sometimes-recycled) externalPath, an honest posted_at_is_exact flag instead of silently mis-parsing relative date text, and single-URL-paste onboarding (no need to separately supply tenant/site/wdServer).