Workday Jobs Scraper - Real Locations, No API Key

Workday jobs with real locations

For recruiters and hiring-market research, collect public Workday job postings with the advertised locations behind collapsed multi-location labels.

Coverage: Supported myworkdayjobs.com career sites only. Field availability and access depend on the employer's public site.

Open this Actor in Console · First run · Results · Cost · Full guide

Try this Actor

1. Choose one of the included career-site URLs, lower the per-company posting cap, and keep Fetch job details on to inspect expanded locations.
2. Open the dataset and compare the original location label with the locations array. Check SUMMARY for company failures and time or spending stops.

Read the results correctly: Remote type is tenant-dependent, and no structured salary is inferred. New-postings history advances only for saved results; an empty repeat is not proof of no hiring.

Result preview

The dataset view highlights these columns:

• Workday tenant · company
• Job title · title
• Original location label · locationsText
• Reported location count · locationCount
• Advertised locations · locations
• Posting date · postedDate

Use the original source links and the field definitions below when interpreting the results. CSV works well for flat columns; JSON preserves nested values.

Usage and pricing

Base result rate on the FREE tier: $1 per 1,000 results. The Pricing tab shows your plan's result rate and any Actor Start charge. Set a small result limit for the first run; the requested limit is not a guarantee of that many results.

---

Full guide

Scrape live job postings from any company's Workday career site (*.myworkdayjobs.com) and export them to CSV, JSON or Excel. Give the Actor the career-site URL you see in your browser; it reads the same public JSON the career page itself calls, so there is no API key, no login and no proxy to configure.

The part that makes this different: Workday's job list collapses multi-city roles into a label like "12 Locations". Most exports stop there. This Actor opens each of those postings and writes the real list of twelve cities into a locations array, plus locationCount, alongside the raw label.

This Actor reads Workday career sites and nothing else. If an employer you want is not on Workday, this is not the Actor for them - an entry that is not a *.myworkdayjobs.com career site is skipped with a warning rather than quietly fetched from somewhere else.

Typical uses: job-board aggregation, recruiting and talent-market research, competitor hiring signals, tracking where a company is opening headcount, and feeding an "new openings since yesterday" alert.

---

What you get

One row per posting, same shape for every employer.

Field	Type	Notes
company	string	Workday tenant (nvidia)
source	string	Always "workday" - the system the row came from. Constant, and also part of the change-detection key
tenant	string	Workday tenant
site	string	Workday career-site name
jobId	string	Requisition id (JR336652)
title	string	Job title
locationsText	string	Exactly what the job list shows, including "12 Locations"
locations	array	The real locations. Filled from the detail call when fetchDetails is on
locationCount	number	Length of locations (falls back to the number in the label)
locationsExpanded	boolean	true when a collapsed "N Locations" label was opened into real cities
postedOn	string	Workday's human label (Posted Today, Posted 30+ Days Ago)
postedDate	string	YYYY-MM-DD. Exact when details are fetched; derived from the label otherwise. "30+ Days Ago" is left null rather than guessed
timeType	string	Full time / Part time
remoteType	string	Tenant-dependent: Salesforce publishes Office - Flexible, NVIDIA publishes nothing
url	string	Public posting URL
descriptionText	string	Plain text, HTML stripped, capped at 5,000 characters. Present only when fetchDetails is on
scrapedAt	string	ISO timestamp of the fetch

A SUMMARY record is written to the run's key-value store with per-company counts, the reason any company failed, and whether the run stopped early on its time budget.

---

Input

Field	Type	Default	What it does
companies	array	NVIDIA + Salesforce career sites	One entry per employer. Paste the career-site URL as-is (https://nvidia.wd5.myworkdayjobs.com/NVIDIAExternalCareerSite); a /en-US/ segment or a link to a single job is fine. A `tenant
searchText	string	(empty)	Passed to Workday's own search, which matches title and description
maxResultsPerCompany	integer	40	Postings per employer. Workday serves 20 rows per request, so 40 is two list calls
fetchDetails	boolean	true	Opens each posting for the real locations, exact posting date, time type, remote type and description
onlyNewSinceLastRun	boolean	false	Emit only postings that were not in the previous run's baseline
stateStoreName	string	workday-jobs-scraper-state	Named key-value store holding that baseline
maxRunSeconds	integer	240	Wall-clock budget. The run stops cleanly at this point and keeps what it has

Finding your company's career-site URL

Open the employer's "Search jobs" page. If the address bar reads

https://salesforce.wd12.myworkdayjobs.com/en-US/External_Career_Site

then salesforce is the tenant, wd12 is the data centre and External_Career_Site is the site name. Paste the whole URL - the Actor pulls the three pieces out of it. Both the data centre number and the site name are case- and spelling-sensitive, and the Actor tells you which of the two is wrong if a company fails.

---

Example output

A real row from a default run (description truncated here for readability):

{
  "company": "salesforce",
  "source": "workday",
  "tenant": "salesforce",
  "site": "External_Career_Site",
  "jobId": "JR336652",
  "title": "Success Architect - Agentforce (U.S. Citizen)",
  "locationsText": "12 Locations",
  "locations": [
    "Illinois - Chicago",
    "Massachusetts - Boston",
    "Washington - Seattle",
    "Massachusetts - Burlington",
    "Washington - Bellevue",
    "Texas - Dallas",
    "California - Irvine",
    "Colorado - Denver",
    "Georgia - Atlanta",
    "Indiana - Indianapolis",
    "Virginia - Mclean",
    "Texas - Austin"
  ],
  "locationCount": 12,
  "locationsExpanded": true,
  "postedOn": "Posted Today",
  "postedDate": "2026-09-23",
  "timeType": "Full time",
  "remoteType": "Office - Flexible",
  "url": "https://salesforce.wd12.myworkdayjobs.com/External_Career_Site/job/Illinois---Chicago/Agentforce-Success-Architect_JR336652",
  "descriptionText": "To get the best candidate experience, please consider applying for a maximum of 3 roles within 12 months...",
  "scrapedAt": "2026-09-24T01:25:44.304Z"
}

The run that produced this row wrote 80 postings from two employers in 9 seconds, 27 of which had a collapsed "N Locations" label that was expanded into real cities.

---

FAQ

Why does Workday show "12 Locations" instead of the cities, and what does this Actor do about it? Workday's list endpoint returns a single locationsText string per posting, and for multi-city requisitions that string is just a count. The city list only exists on the individual posting. When fetchDetails is on, this Actor opens each posting and writes every location into the locations array, keeping the original label in locationsText so nothing is lost.

Do I need an API key, a Workday account or a proxy? No. These are the employers' own public career-site endpoints and they answer anonymous requests, with no key and no account. Some employers do restrict their career-site JSON to non-datacentre traffic; if one of yours does, the run reports it as an HTTP 403 for that company, tells you a proxy is the only thing that would change it, and carries on with the rest. If you hit that, switch the run to a residential proxy in the Actor's run settings.

The employer I want is not on Workday - can this Actor still get them? No. This Actor speaks Workday's career-site API only, and it will not silently fall back to a different job-posting system just to return rows. A non-Workday entry is skipped with a warning naming what a valid career-site URL looks like. Check the employer's "Search jobs" page: if the address bar is not *.myworkdayjobs.com, they are on another platform and you want a scraper built for that platform.

What happens on the first run with "Only postings new since the last run" turned on? There is no baseline yet, so everything is returned and saved as the baseline; the log says so plainly. From the second run on you get only postings that were not there before, and an empty dataset means nothing new was posted. The baseline lives in a named key-value store (stateStoreName), so give separate scheduled jobs separate names.

Can I get salary or compensation data? There is no separate pay field in Workday's public career-site JSON, so this Actor does not invent one. Where an employer states a pay range, it is inside the posting text and therefore inside descriptionText.

Why does a big employer report exactly 2,000 results? Workday's total saturates at 2000 on large boards (NVIDIA reports 2000 with or without a search term), so it is an estimate of board size, not a precise count. Use searchText to narrow a large board instead of trying to page through all of it.

---

Data source, access and limits

• Where the data comes from. Every row comes from the employer's own career-site API, https://{tenant}.wd{N}.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs and the matching per-job endpoint. These are the public, keyless endpoints the career pages themselves use. Nothing here is behind a login. Every row is an employer-published job advertisement, not a person: the Actor collects no candidate, applicant or employee data, and it never touches an employer's applicant-tracking data. Note that descriptionText reproduces the employer's own advertisement text verbatim, and some employers print a recruiting or accommodation-request mailbox in it. Those addresses are the employer's own published contact details. Turn fetchDetails off if you would rather not store the ad text at all.
• Page size. Workday caps its list endpoint at 20 rows per request (21 returns HTTP 400), so a 1,000-posting board is 50 sequential list calls plus one detail call per posting. Budget time accordingly with maxRunSeconds.
• Politeness. Requests are sequential per employer with a short pause between list pages; detail lookups run at most five at a time.
• Time budget. The run stops cleanly when it reaches maxRunSeconds (or the platform run timeout), keeps everything collected so far, and logs exactly how much was left and what to change. A partial run is a successful run with a warning, not a failure.
• Failures are loud. If one employer's URL is wrong, that company is reported with the specific reason (wrong site name vs wrong wd data centre) and the others still run. If every employer fails, the run fails rather than handing you an empty file that looks like "no jobs".
• Freshness. Every row is fetched live at run time; nothing is served from a cache.
• Billing. This Actor is a paid Actor: the price and pricing model in force are the ones shown on its Apify Store page and on the run screen before you start a run. Apify platform usage (compute units, storage) is charged on top under your own plan. Use maxResultsPerCompany and maxRunSeconds to cap the size of a run.

Saved rows and run charge limits

The Actor writes results one at a time and stops when Apify reports the run charge limit. SUMMARY.stoppedOnChargeLimit distinguishes that stop from an empty source. Saved-row counts include only rows accepted by the dataset. For change detection, prior seen IDs are retained and newly discovered IDs enter the baseline only after their row is saved; rows excluded by a result or charge cap remain eligible for a later run. Avoid concurrent monitor runs sharing the same named baseline store.

Help with your run

Open the Issues tab on this Actor with the run URL, the input field that caused trouble and what you expected to receive. Remove API keys and private information before posting.

Explore more Mayd-It Actors

Understand your run

Open Run report in the run’s Output tab for saved-record counts, reported source issues and limits, and suggested next steps. Use CSV export to take the saved results into a spreadsheet. The existing JSON results and detailed machine-readable summary remain available.

The report reflects this run’s recorded coverage. A successful run or a saved result does not establish that every possible source record was collected.