It's the feed Lever runs so companies can show their jobs on their own sites, so it's meant to be read. Cache what you fetch and don't poll it in a tight loop.

1. Find the site name, and the region

Every call starts with the company's site name: the first path segment of its Lever board. jobs.lever.co/zoox means the site is zoox. Job links look like jobs.lever.co/zoox/<uuid>, so any "Apply" link gives it away.

Lever has two regions. A board at jobs.eu.lever.co/<site> is served from api.eu.lever.co, not api.lever.co. The trap is that the wrong host doesn't always say so. Lever's own board lives on the EU host:

$ curl -s -w "\n%{http_code}\n" "https://api.lever.co/v0/postings/lever?mode=json"
[]
200

$ curl -s "https://api.eu.lever.co/v0/postings/lever?mode=json"   # 6 postings

An empty array with a 200 looks like "no open jobs". Before you conclude that, try the other host.

2. List the jobs: GET /v0/postings/{site}?mode=json

curl "https://api.lever.co/v0/postings/zoox?mode=json"

The response is a bare JSON array, no wrapper and no total. (Today it answered JSON even without mode=json; I keep the parameter in anyway.) Zoox returned 236 postings, Spotify 81, Palantir 304 (a 5.9 MB response, because every posting carries its full description). One Zoox posting, trimmed:

{
  "id": "e8a190f0-7a89-4c11-a6a0-452ff6234749",
  "text": "Administrative Business Partner, Floater",
  "createdAt": 1791307664932,
  "categories": {
    "commitment": "Full-time",
    "department": "Executive Office",
    "location": "Foster City, CA",
    "team": "Executive Office",
    "allLocations": ["Foster City, CA"]
  },
  "country": "US",
  "workplaceType": "hybrid",
  "salaryRange": {
    "min": 123000,
    "max": 168000,
    "currency": "USD",
    "interval": "per-year-salary"
  },
  "hostedUrl": "https://jobs.lever.co/zoox/e8a190f0-7a89-4c11-a6a0-452ff6234749",
  "applyUrl": "https://jobs.lever.co/zoox/e8a190f0-7a89-4c11-a6a0-452ff6234749/apply"
}

The title is text, not title. hostedUrl is the page a candidate should see.

createdAt is milliseconds

createdAt is a Unix timestamp in milliseconds. 1791307664932 is 2026-10-06. Feed it to a function expecting seconds and you land tens of thousands of years in the future. Divide by 1000 first:

from datetime import datetime, timezone
datetime.fromtimestamp(1791307664932 / 1000, tz=timezone.utc)
# 2026-10-06 17:27:44.932000+00:00

It's the only date in the response. There's no "updated" field. And it's not always recent: Palantir's oldest open posting has a createdAt in December 2009, while 5 of its 304 were created in the past week.

Pagination: skip and limit

The plain call returns everything. To page, add skip and limit:

curl "https://api.lever.co/v0/postings/zoox?mode=json&skip=0&limit=3"
curl "https://api.lever.co/v0/postings/zoox?mode=json&skip=3&limit=3"

The two pages returned postings 1-3 and 4-6 of the full list, in the same order. There's no total or "next" marker: keep going until a page comes back shorter than limit.

3. Filters

The endpoint filters server-side on the categories values. All of these ran against Spotify's 81 postings:

Three things fall out of that table:

• Matching is exact and case-sensitive. london matches nothing. Take values from the data, not from a guess.
• Repeating a parameter ORs the values.
• location matches allLocations, not just the primary location. Only 31 Spotify postings have London as categories.location, but 37 come back, because multi-location jobs list it in allLocations.

level works too: Zoox has 20 postings with level "All Levels", and level=All%20Levels returned those 20. Most companies don't fill it in. Palantir and Spotify have no level on any posting, and Palantir has no department either, only team.

group=team changes the shape of the response. Instead of a flat array you get one object per team, each with title and postings:

curl "https://api.lever.co/v0/postings/spotify?mode=json&group=team"

Spotify came back as 23 groups ("Accounting", "Experience", ...) holding the same 81 postings.

4. One posting: GET /v0/postings/{site}/{id}

curl "https://api.lever.co/v0/postings/zoox/e8a190f0-7a89-4c11-a6a0-452ff6234749"

This returns a single object with the same fields as in the list. No mode=json is needed here.

5. The fields worth knowing

• workplaceType: onsite, hybrid or remote. Spotify had 40 hybrid, 28 remote and 13 onsite. Unlike Greenhouse, Lever gives you a real remote flag.
• salaryRange: present only when the company publishes it. 222 of Zoox's 236 postings had one (mostly USD per year, 8 per-hour-wage, 1 in GBP); Spotify and Palantir had none. Check interval before you compare numbers. Postings with a range usually also carry salaryDescription / salaryDescriptionPlain, the company's free-text pay note.
• description vs descriptionPlain: the intro as HTML and as plain text. Unlike Greenhouse, the HTML isn't double-escaped, so it renders as is.
• lists: the bulleted sections, each with a text heading and HTML content of <li> items. The Zoox posting has "Responsibilities", "Qualifications" and "Bonus Qualifications". To rebuild the full job description, concatenate description, each list, and additional.
• additional / additionalPlain: the closing text, often the equal-opportunity statement or office rules ("this role does require an onsite presence in our Foster City, CA office between 3-5 days per week").
• opening and descriptionBody: newer fields that split the intro, also with Plain versions. Usage varies: opening was filled on 300 of Palantir's 304 postings, 4 of Spotify's 81 and none of Zoox's.

6. Wrong site, wrong id

$ curl -s -w "\n%{http_code}\n" "https://api.lever.co/v0/postings/notarealcompany12345?mode=json"
{"ok":false,"error":"Document not found"}
404

A wrong posting id on a real site gives the same 404 body. But as section 1 showed, a site that exists only on the other region can return [] with a 200. Mistral returned [] on the US host and 404 on the EU host. So: 404 means wrong name; [] means no jobs on this host, so check the other one.

7. The apply endpoint: leave it alone

The posting URL also accepts a POST, which is how a custom careers page submits an application:

$ curl -s -X POST -w "\n%{http_code}\n" https://api.lever.co/v0/postings/zoox/e8a190f0-7a89-4c11-a6a0-452ff6234749
{"ok":false,"error":"You need an API key. Please contact support@lever.co for a key"}
403

That key belongs to the company. Stick to the read side.

Summary

If you need more than Lever

One Lever client is an afternoon's work. If you're watching companies across several ATSs, I maintain an Apify Actor, Company Jobs API, that reads Lever (US and EU) plus Greenhouse, Workday, Ashby, Workable, SmartRecruiters, Recruitee and Personio and returns all of them in one schema. You can pass a careers URL like https://jobs.lever.co/zoox or just a company name or domain, and it finds the board. It costs $0.001 per job returned; jobs your filters drop and companies it can't find are free. Turn on Only new jobs, schedule it daily, and each run returns only postings that appeared since the last one.

It's the feed Greenhouse runs so careers pages and job boards can show a company's jobs, so it's meant to be read. Still: cache what you fetch and don't poll it in a tight loop.

1. Find the board token

Every Greenhouse call starts with the company's board token, a short slug like discord. There are three places to find it.

The board URL. Older links look like boards.greenhouse.io/<token>, newer ones job-boards.greenhouse.io/<token>. The old host now redirects to the new one:

$ curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}\n" https://boards.greenhouse.io/discord
301 -> https://job-boards.greenhouse.io/discord

Either way, the token is the first path segment.

A gh_jid in the company's own careers URL. Many companies keep the jobs on their own domain and embed Greenhouse. The giveaway is a gh_jid query parameter: that's the Greenhouse job id. Stripe's jobs link to https://stripe.com/jobs/search?gh_jid=8172510 and Airbnb's to https://careers.airbnb.com/positions/7789554?gh_jid=7789554. The id tells you it's Greenhouse; it doesn't tell you the token, so try the company name (stripe, airbnb) against the API in step 2. A 200 means you guessed right.

A grnh.se short link. That domain is Greenhouse's (the bare https://grnh.se/ redirects to www.greenhouse.io). If a job link uses it, follow the redirect and read the token or gh_jid from where it lands.

If the page embeds the board with an iframe, the embed URL carries the token as for=: boards.greenhouse.io/embed/job_board?for=discord.

2. List the jobs: GET /v1/boards/{token}/jobs

curl "https://boards-api.greenhouse.io/v1/boards/discord/jobs"

The response has two keys, jobs and meta. Discord returned 44 jobs and "meta": {"total": 44}. One of them, trimmed:

{
  "absolute_url": "https://job-boards.greenhouse.io/discord/jobs/8806482002",
  "internal_job_id": 6524134002,
  "location": { "name": "San Francisco Bay Area" },
  "id": 8806482002,
  "updated_at": "2026-10-20T20:27:20-04:00",
  "requisition_id": "R-107406",
  "title": "Commercial Policy Lead",
  "company_name": "Discord",
  "first_published": "2026-09-15T12:52:11-04:00",
  "language": "en",
  "application_deadline": null
}

Every job also carries metadata (the company's custom fields, here "Featured on Website" and "Careers Site Department"), data_compliance (GDPR consent flags) and, for most, education. absolute_url is the link a candidate should follow, and it points wherever the company hosts its board: for Stripe it's the stripe.com/...?gh_jid= URL, not a greenhouse.io one.

Three things to know:

• There is no pagination. One request returns the whole board. Stripe returned 725 jobs in one 452 KB response, with meta.total 725.
• There is no auth on any of the read endpoints in this article.
• The plain list has no departments or offices. Those fields only appear with ?content=true or on the single-job endpoint (sections 3 and 4).

Which date to use

There are two timestamps, and they mean different things:

• first_published: when the posting first went live.
• updated_at: the last time anything on it changed.

On Discord's board all 44 jobs had an updated_at in the past week, but only 1 had a first_published in it (the oldest went live on 2025-10-30). Use first_published for "new jobs this week". updated_at makes everything look fresh.

A wrong token

$ curl -s -w "\n%{http_code}\n" https://boards-api.greenhouse.io/v1/boards/notarealcompany12345/jobs
{"status":404,"error":"Job not found"}
404

The message says "Job not found" even though it's the board that's missing. A wrong job id on a real board (/v1/boards/discord/jobs/1) gives the identical 404 body, so you can't tell the two apart from the response. Check the token with the plain list first.

3. Descriptions: ?content=true

curl "https://boards-api.greenhouse.io/v1/boards/discord/jobs?content=true"

This adds content (the job description), departments and offices to each job, plus the ai_disclaimer, include_ai_disclaimer and ai_opt_out_request_url fields. It's much heavier: Stripe's board went from 452 KB to 5.6 MB.

The description is HTML that has been HTML-escaped a second time. The raw value starts like this:

<div class="content-intro"><p>Discord has a highly engaged community of millions ...

Unescape it once and you get the real markup:

import html, json, urllib.request

url = "https://boards-api.greenhouse.io/v1/boards/discord/jobs?content=true"
jobs = json.load(urllib.request.urlopen(url))["jobs"]
description_html = html.unescape(jobs[0]["content"])
# '<div class="content-intro"><p>Discord has a highly engaged community ...'

If you render content without unescaping it, the reader sees literal tags.

4. One job: GET /v1/boards/{token}/jobs/{id}

curl "https://boards-api.greenhouse.io/v1/boards/discord/jobs/8806482002"

This returns the same fields as a job in the ?content=true list, including content, departments and offices. Use it when you already have the id, for example from a gh_jid.

Salary: ?pay_transparency=true

Salary ranges are off by default. Add pay_transparency=true and jobs gain a pay_input_ranges array:

curl "https://boards-api.greenhouse.io/v1/boards/discord/jobs/8806482002?pay_transparency=true"

"pay_input_ranges": [
  {
    "min_cents": 19200000,
    "max_cents": 21600000,
    "currency_type": "USD",
    "title": "Base Salary",
    "blurb": "<p><em>The base salary range for this full-time position is listed below. ..."
  }
]

That's $192,000 to $216,000, in cents. The parameter works on the list too: on Discord's board 41 of 44 jobs had a non-empty range. It only shows what the company entered, though. Stripe's 725 jobs all came back with no range.

Application form: ?questions=true

curl "https://boards-api.greenhouse.io/v1/boards/discord/jobs/8806482002?questions=true"

This adds the application form: questions, location_questions, compliance (EEOC questions such as veteran status) and demographic_questions. The Discord job had 13 questions, starting with First Name, Last Name, Preferred First Name, Email, Phone, Resume/CV and Cover Letter, then company questions such as "Why do you want to work at Discord?". Each has a label, required flag and fields with a name and type (input_text, input_file, textarea, multi_value_single_select...). Resume/CV accepts either input_file or textarea.

5. Group jobs: /departments and /offices

curl "https://boards-api.greenhouse.io/v1/boards/discord/departments"
curl "https://boards-api.greenhouse.io/v1/boards/discord/offices"

/departments returns {"departments": [...]}. Each department has id, name, parent_id, child_ids and its jobs. Discord has 58 departments, and only 15 had open jobs: Product Engineering 12, Developers 6, Data Science & Engineering 6, Product Design 5, the rest fewer. parent_id and child_ids give you the hierarchy, so you can roll jobs up to a top-level group.

/offices returns {"offices": [...]}, each with id, name, location, parent_id, child_ids and a departments tree with jobs inside. Discord has 14 offices. Counting jobs per office: San Francisco 33, Remote (US) 10, and one each in Lisbon, Los Angeles, New York and Washington, D.C. That sums to 47 for 44 jobs, because a job can be in more than one office. Count unique job ids if you need totals.

Office names are whatever the company typed. Discord's list includes Workday_Test and No Office, and location can be null (Canada, Remote (US)). There is also no remote flag anywhere in the API. "Remote" only appears in office and location text.

6. The application endpoint: leave it alone

The same URL accepts a POST, which is how a careers page submits an application. Without credentials:

$ curl -s -X POST -w "\n%{http_code}\n" https://boards-api.greenhouse.io/v1/boards/discord/jobs/8806482002
HTTP Basic: Access denied.
401

Submitting needs the company's own Job Board API key, which only the company has. Stick to the read side.

Summary

If you need more than Greenhouse

One Greenhouse client is an afternoon's work. If you're watching companies across several ATSs, I maintain an Apify Actor, Company Jobs API, that reads Greenhouse plus Workday, Lever, Ashby, Workable, SmartRecruiters, Recruitee and Personio and returns all of them in one schema. You can pass a careers URL like https://boards.greenhouse.io/stripe or just a company name or domain, and it finds the board. It costs $0.001 per job returned; jobs your filters drop and companies it can't find are free. Turn on Only new jobs, schedule it daily, and each run returns only postings that appeared since the last one.

It's the careers page's own backend, not a feed built for you, so treat it gently: read the tenant's robots.txt, keep one or two requests in flight, and cache what you fetch.

1. Read tenant, host and site from the careers URL

A Workday careers URL carries three things you need:

https://nvidia.wd5.myworkdayjobs.com/NVIDIAExternalCareerSite
        ^^^^^^ ^^^                    ^^^^^^^^^^^^^^^^^^^^^^^^
        tenant host (data centre)     site

• tenant: the first label of the hostname (nvidia).
• host: wd1, wd3, wd5, wd12... It's the Workday data centre the company lives in. You can't guess it, so start from a real careers link.
• site: the first path segment (NVIDIAExternalCareerSite). One tenant can have several sites (internal, university, a recruiting-ads site).

Many links carry a locale first: https://salesforce.wd12.myworkdayjobs.com/en-US/External_Career_Site. The locale is not the site. If you take the first segment blindly, the API tells you so:

POST https://salesforce.wd12.myworkdayjobs.com/wday/cxs/salesforce/en-US/jobs
-> 404 {"errorCode":"S21", ..., "message":"not found: Job_Posting_Site_ID=en-US"}

Skip a leading segment that looks like a locale (xx-XX or xx) and take the next one: External_Career_Site.

2. List jobs: POST /wday/cxs/{tenant}/{site}/jobs

curl -X POST "https://nvidia.wd5.myworkdayjobs.com/wday/cxs/nvidia/NVIDIAExternalCareerSite/jobs" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"appliedFacets":{},"limit":20,"offset":0,"searchText":""}'

The response has four keys: total, jobPostings, facets and userAuthenticated. A posting in the list is thin:

{
  "title": "Senior Cell Modeling and Verification Engineer",
  "externalPath": "/job/US-CA-Santa-Clara/Senior-Cell-Modeling-and-Verification-Engineer_JR2015659",
  "locationsText": "US, CA, Santa Clara",
  "postedOn": "Posted Today",
  "bulletFields": ["JR2015659"]
}

The body fields:

• limit: page size, 20 at most. "limit":21 got 400 {"errorCode":"HTTP_400", ...} with an empty message.
• offset: where the page starts.
• searchText: the careers page's search box. "CUDA" gave total: 530.
• appliedFacets: filters, covered in section 4.

The headers matter more than they look. Both errors come back with no message:

So set both headers explicitly. An HTTP client that defaults to Accept: text/html, or one that posts form data, fails in ways that look like an outage.

3. Paginate: total is only on page 1, and the list stops at 2,000

Page one said "total": 2000. Page two (offset: 20) said "total": 0, with 20 postings in it. Read total from the first response and keep it; don't loop "while total > offset" on every page.

The 2,000 is not NVIDIA's real job count. It's a cap. The facets on the same response count the jobs per category, and those add up to more: the timeType facet alone says Full time 2,713 + Part time 2. Workday serves at most 2,000 postings per list.

And past the cap it doesn't return an empty page. offset: 1980 returned the last 20 (all "Posted 30+ Days Ago"). offset: 2000 returned page one again, starting with the same "Senior Cell Modeling and Verification Engineer". A loop that stops on an empty page never stops; one that stops at total is fine, as long as total came from page one.

4. Split a big tenant with facets

To get past 2,000, ask for smaller lists. Each entry in facets has a facetParameter and values with an id, a descriptor and a count. NVIDIA's first page returned:

locationMainGroup is a group: the filterable parameters are the nested ones (locationHierarchy1 for countries, locations for sites). Facet names vary by tenant; Salesforce's site also had a custom one, CF_-_REC_-_LRV_-_Job_Posting_Anchor_-_Country_from_Job_Posting_Location_Extended. Read them from the response rather than hard-coding them.

Filter by passing the value ids under their parameter:

curl -X POST "https://nvidia.wd5.myworkdayjobs.com/wday/cxs/nvidia/NVIDIAExternalCareerSite/jobs" \
  -H "Content-Type: application/json" -H "Accept: application/json" \
  -d '{"appliedFacets":{"jobFamilyGroup":["0c40f6bd1d8f10ae43ffaefd46dc7e78"]},"limit":20,"offset":0,"searchText":""}'

That's Engineering, and it returned "total": 1724, the same number the facet promised, and under the cap. Sales returned 331. So the recipe is: read the facet counts from page one; for every value under 2,000, page through it; for any value still over 2,000, add a second facet (country inside Engineering, say). Jobs can sit in several location values, so dedupe on externalPath or the requisition id in bulletFields.

5. Exact dates come from the detail call

postedOn is relative text: "Posted Today", "Posted 3 Days Ago", and for anything older, "Posted 30+ Days Ago". You can turn the first two into a date, but the last one only tells you "at least 30 days".

The detail endpoint is the same base plus the posting's externalPath, as a GET:

curl "https://nvidia.wd5.myworkdayjobs.com/wday/cxs/nvidia/NVIDIAExternalCareerSite/job/UK-Remote/Developer-Relations-Manager--Physical-AI-Healthcare---EMEA_JR2021575" \
  -H "Accept: application/json"

Its jobPostingInfo said "postedOn": "Posted 30+ Days Ago" and "startDate": "2026-07-30": almost three months, not one. The newer job above had "startDate": "2026-10-21". The detail object also has jobDescription (HTML), timeType, jobReqId, location, country (with alpha2Code under jobRequisitionLocation), canApply and externalUrl, the public link to send people to. I saw no salary field.

That's one request per job, so for a 2,700-job tenant it's the expensive part. Fetch details only for postings you haven't seen before.

6. Be polite

NVIDIA's robots.txt allows /NVIDIAExternalCareerSite/ and disallows /NVIDIAExternalCareerSiteResearch/, /talentcommunity/, /NVIDIARecruitAds/ and /refreshFacet/. Check it per tenant and per site before you crawl. The same file points to a sitemap, /NVIDIAExternalCareerSite/siteMap.xml. Keep a few requests in flight per host, back off on errors, and don't re-fetch details for jobs you already have.

If you need this for many companies

Everything above works with curl. If you'd rather not maintain it, I built the Company Jobs API on Apify. You give it Workday careers URLs (with or without a locale like /en-US/), and it returns one row per job in the same schema it uses for seven other ATSs: Greenhouse, Lever, Ashby, Workable, SmartRecruiters, Recruitee and Personio. It costs $0.001 per job returned. With "Only new jobs" on and a daily schedule, each run returns just the postings that appeared since the last one. For Workday it keeps to the site's robots.txt and at most 4 requests at a time per company. It doesn't split by facets yet: for employers over the cap you get the newest 2,000, and the run log says so. Exact dates for "30+ days" jobs come from the detail call, made only for jobs that pass your filters.

These feeds are meant to be read. Be polite: cache results, don't hammer them, and back off on a 429.

Step zero: find the company's board slug

The slug is the last path segment (or the subdomain) of the careers page, and you find it by following the "Apply" link on any job:

Companies that serve their board from their own domain (Stripe's jobs link is stripe.com/jobs/search?gh_jid=8172510) can still be on one of these systems: the absolute_url in Stripe's Greenhouse response is exactly that link. When there is no giveaway, try the company name as a slug against each API below. Greenhouse, Lever and Ashby all answer 404 for an unknown company, so a 200 tells you which ATS it is.

Greenhouse

curl "https://boards-api.greenhouse.io/v1/boards/stripe/jobs?content=true"

• Everything comes back in one response, with no pagination. Stripe returned 729 jobs, and meta.total says 729.
• Top-level keys are jobs and meta. Each job has id, title, location.name, absolute_url, first_published, updated_at, departments, offices and company_name.
• content=true adds the description. It is HTML that has been HTML-escaped (<h2>...), so unescape it before you render it. For Stripe the response is 455 KB without it and 5.7 MB with it, so leave it off if you only need titles.
• One job: GET /v1/boards/stripe/jobs/8172510. Board name: GET /v1/boards/stripe, which returned {"name":"Stripe","content":""}.
• There is no remote flag. Remote only shows up in the location text.
• Salary: my earlier notes say it appears in pay_input_ranges (min_cents, max_cents, currency_type) when a company publishes it. None of Stripe's 729 jobs had that field today, so I can't show real output for it.
• Unknown board: HTTP 404 with {"status":404,"error":"Job not found"}.

Lever

curl "https://api.lever.co/v0/postings/spotify?mode=json"
curl "https://api.lever.co/v0/postings/spotify?mode=json&skip=0&limit=5"

• Without limit you get a bare JSON array of everything (Spotify: 80 postings). With skip and limit you page through it: limit=5 returned the first five of the same list.
• Fields: id, text (the title), categories (commitment, department, location, team, allLocations), country, workplaceType (hybrid on the first Spotify posting), hostedUrl, applyUrl, descriptionPlain, description, lists and additional.
• createdAt is a Unix timestamp in milliseconds, not an ISO string. Spotify's first posting had 1791566108174, which is 2026-10-09.
• There are two regions. Companies hosted at jobs.eu.lever.co live on api.eu.lever.co and answer 404 on the US host, so try both before giving up.
• Salary, where published, is in salaryRange. None of Spotify's postings had it today.
• Unknown company: HTTP 404 with {"ok":false,"error":"Document not found"}.

Ashby

curl "https://api.ashbyhq.com/posting-api/job-board/notion?includeCompensation=true"

• One response, no pagination: {"apiVersion": ..., "jobs": [...]}. Notion had 137 jobs.
• Fields: id, title, department, team, employmentType (FullTime), location, secondaryLocations, publishedAt, isListed, isRemote, workplaceType, address, jobUrl, applyUrl, descriptionHtml and descriptionPlain.
• Remote is not clean. In Notion's data, 86 jobs had isRemote: true together with workplaceType: "Hybrid", and 51 had both set to null. Don't treat isRemote as a reliable filter. Read workplaceType and the location text as well.
• includeCompensation=true adds a compensation object with compensationTierSummary, compensationTiers and summaryComponents. Notion's were all empty today, so check for that before you read a salary.
• Unknown company: HTTP 404 with the body Not Found.

Workday

Workday has no public jobs API. Every *.myworkdayjobs.com careers site loads its listings from a JSON endpoint that the page itself calls, and that is what you read here. It is the careers page's own backend, not a published feed, so check the tenant's robots.txt and keep only a few requests in flight.

Three parts of the URL come from the careers page and none of them can be guessed: the tenant (pfizer), the data-centre host (wd1, wd5, wd12...) and the site name (PfizerCareers). Drop any locale segment such as /en-US/.

curl -X POST "https://pfizer.wd1.myworkdayjobs.com/wday/cxs/pfizer/PfizerCareers/jobs" \
  -H "Accept: application/json" -H "Content-Type: application/json" \
  -d '{"appliedFacets":{},"limit":20,"offset":0,"searchText":""}'

What I saw today:

• The response has total (560 for Pfizer), jobPostings, facets and userAuthenticated. A posting has title, externalPath, locationsText, postedOn ("Posted 12 Days Ago") and bulletFields (the requisition id).
• limit above 20 is rejected. I sent 21 and got HTTP 400.
• total is only filled in on the first page. At offset: 20 it came back as 0 while still returning 20 jobs, so read it once and don't trust it after that.
• Content-Type: application/json is required: without it I got HTTP 500. The Accept header was not required in my test (HTTP 200 without it), but I send it anyway.
• Search works server-side: "searchText":"data engineer" with limit: 5 returned total: 80.
• A tenant that doesn't exist answered HTTP 422 for me, not 404, so check the status code and the presence of jobPostings.
• A site serves at most 2,000 postings. Past that, offsets hand back the first page again, so de-duplicate on externalPath. I saw this on an earlier test (18 October); Pfizer has too few jobs to show it today.
• The list has no real date or description: older jobs just say "Posted 30+ Days Ago". For those, GET the detail:

curl "https://pfizer.wd1.myworkdayjobs.com/wday/cxs/pfizer/PfizerCareers/job/United-States---New-York---Pearl-River/Facilities-Engineer---Electrical-and-Controls_4965638-1" \
  -H "Accept: application/json"

That is .../wday/cxs/<tenant>/<site> plus the posting's externalPath. The jobPostingInfo object has jobDescription (HTML), startDate (2026-10-09 for that job), timeType ("Full time"), jobReqId, location, country and endDate. There is no salary field. The public job page is https://pfizer.wd1.myworkdayjobs.com/PfizerCareers plus the externalPath.

The other four, quickly

All calls below were run today.

If you'd rather not maintain eight parsers

The gotchas add up: several pagination styles, a millisecond timestamp, a 200-for-nothing, a Workday host you have to know in advance. If you only need one company, the curl calls above are enough.

If you want many companies in one schema, I built the Company Jobs API on Apify. You give it careers page URLs, domains or company names, it finds the ATS (Workday needs the full careers URL), and it returns one row per job with the same fields whatever the source. It covers the eight ATSs in this article. It costs $0.001 per job returned; jobs your filters drop and companies it can't find are free. It also has a monitor mode: schedule it daily with "Only new jobs" on, and each run returns just the postings that appeared since the last one. You don't need it to use anything above.

I'm Jordan Belfort, and I build open job-data tools. If an endpoint here has changed, tell me and I'll fix the article.