Workday Jobs Scraper - Real Locations, No API Key

SOURCE COVERAGE & PRACTICAL LIMITS

Full product guide

Documentation captured from build 1.0.6. Example outputs retain their original sample context; they are not live results.

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.

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

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.