DEV Community: Adderley Data

The Rippling job board API, measured: a 1,000-row list, a record per job and pay by tier

Adderley Data — Sun, 25 Oct 2026 18:45:34 +0000

Rippling's applicant tracking system gives each customer a job board at ats.rippling.com/{slug}/jobs. The page is a shell: its jobs arrive from api.rippling.com as JSON, in two steps, one list of postings and then one record per posting. Rippling's developer site has a Job Board API reference, but when we looked on 6 October 2026 it asked for a Rippling sign-in. What follows is the pair of endpoints the public board itself calls, and how they behave.

We read Rippling boards every day. Unless a line gives another date, every figure here was measured against Rippling's own board on 26 October 2026.

The slug

The link to a board carries the only name you need:

https://ats.rippling.com/acme/jobs

acme is the slug, and it is case-sensitive. Rippling's own board is rippling; ask for Rippling and the API answers HTTP 404 with exactly the body it gives for a board that does not exist:

{"error_code": "RESOURCE_NOT_FOUND", "message": "Job Board not found", "resource": null}

So a 404 from the list means "check the slug's case" before it means "this company has left Rippling".

The list

curl "https://api.rippling.com/platform/api/ats/v2/board/rippling/jobs?groupJobsByLocation=true&page=0&pageSize=1000"

The answer has five keys: items, page, pageSize, totalItems and totalPages. Each item is a posting:

{
  "id": "0b6f1c2e-5a7d-4e8b-9c3f-2d1a6e4b7c90",
  "name": "Data Engineer",
  "url": "https://ats.rippling.com/acme/jobs/0b6f1c2e-5a7d-4e8b-9c3f-2d1a6e4b7c90",
  "department": { "name": "Engineering" },
  "locations": [
    {
      "name": "Austin, TX",
      "country": "United States",
      "countryCode": "US",
      "state": "Texas",
      "stateCode": "TX",
      "city": "Austin",
      "workplaceType": "HYBRID"
    }
  ],
  "language": "en-US"
}

workplaceType is ON_SITE, HYBRID or REMOTE, and it belongs to each place, not to the posting.

Paging, and the flag that changes the count

Three things to know before you write the loop:

1,000 a page at most. pageSize=1000 works; pageSize=1001 answered HTTP 400 with {"ok": false, "error": "There was a validation error"}.
Every page says how big the board is, in totalItems and totalPages. A page past the end answers 200 with an empty items list, so a loop that stops on an empty page also ends. Workday's careers API, by contrast, starts again from the top.
groupJobsByLocation=true decides what an item is. With it, Rippling's board answered 377 items, one per posting, each carrying all its places. Without it, the same board answered 649: one item per posting and place, the posting repeated under each. The older list, /platform/api/ats/v1/board/{slug}/jobs, also returns 649 entries, ignores page and pageSize, and gives each place as a bare label such as {"label": "AR", "id": "AR"}.

If you are counting postings, send the flag. If you are counting places, leave it off and remove duplicates by id.

The places themselves have habits. One posting on Rippling's board lists 20 of them; 132 of the 377 list more than one; 26 mix workplace types (on-site in one city, remote in another); and two list the same label twice.

The job record

The list has no date, no pay and no employment type. The record for each posting has all three:

curl "https://api.rippling.com/platform/api/ats/v1/board/rippling/jobs/{id}"

What a jobs table wants from it:

createdOn: an ISO timestamp with an offset and microseconds, such as 2026-03-31T17:37:26.093000-07:00. Nothing in the record says when a posting was last edited.
payRangeDetails: an empty list, or one range or more, each {location, currency, frequency, rangeStart, rangeEnd, isRemote}. Its location is a pay tier or a place: "US Tier 1", "US San Francisco Bay Area", "New York Office".
employmentType: {"label": "SALARIED_FT", "id": "Salaried, full-time"}. The code is in label and the words are in id, the opposite of what the names suggest.
companyName, department (with base_department and department_tree), workLocations as plain labels, and description in two HTML parts, company and role.

Everything else is the board's own settings and the application form (board, activeJobApplication, eeocQuestionnaireEnabled, hasAIEvaluationsEnabled), which a table of jobs can leave alone. An unknown id on a real board answers 404 with {"ok": false, "error": "There was a client validation error"}, worded differently from the list's 404, so match on the status code, not the message.

A script that reads a whole board

For Node 18 or later, with nothing to install. It writes one JSON line per posting:

// rippling-jobs.mjs: every open role on one Rippling job board, with its date and pay (Node 18 or later)
// node rippling-jobs.mjs rippling > jobs.jsonl
const slug = process.argv[2];
if (!slug) throw new Error('Give the board slug: the part after ats.rippling.com/ in the board link');
const api = 'https://api.rippling.com/platform/api/ats';
const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

async function getJson(url) {
  const response = await fetch(url, { headers: { accept: 'application/json' } });
  if (!response.ok) throw new Error(`HTTP ${response.status} for ${url}`);
  return response.json();
}

// 1. The list: up to 1,000 postings a page, one entry per posting with groupJobsByLocation=true.
const postings = [];
for (let page = 0; ; page += 1) {
  const list = await getJson(`${api}/v2/board/${slug}/jobs?groupJobsByLocation=true&page=${page}&pageSize=1000`);
  postings.push(...list.items);
  if (page + 1 >= list.totalPages) break;
  await sleep(700);
}

// 2. One record per posting: the date, the pay and the employment type are only here.
for (const posting of postings) {
  await sleep(700); // one request at a time, under 90 a minute
  const job = await getJson(`${api}/v1/board/${slug}/jobs/${posting.id}`);
  console.log(JSON.stringify({
    id: posting.id,
    title: posting.name.trim(),
    department: posting.department?.name ?? null,
    locations: posting.locations.map(({ name, countryCode, city, workplaceType }) => ({ name, countryCode, city, workplaceType })),
    createdOn: job.createdOn,
    employmentType: job.employmentType?.label ?? null, // the code is in label; the words are in id
    pay: (job.payRangeDetails ?? []).map(({ location, currency, frequency, rangeStart, rangeEnd }) => ({ location, currency, frequency, rangeStart, rangeEnd })),
    url: posting.url,
  }));
}
console.error(`${postings.length} postings`);

Run exactly as printed against Rippling's own board on 26 October 2026, it reported 377 postings: 378 requests (one list page, 377 records), every one answered at the first attempt, in 5 minutes 45 seconds. The titles get a trim() because 67 of the 377 arrived with spaces at one end or both. Keep the pause: these are a company's careers pages, and one request at a time is plenty.

What one board holds

Counted from that run's 377 lines:

Fact	Postings with it	Notes
Country	377 of 377	19 countries: the United States 207, India 92, Ireland 37, Germany 11, Canada 9
City	337 of 377	All 40 without one are remote
Work arrangement	377 of 377	First place listed: on-site 302, remote 56, hybrid 19
Employment type	377 of 377	`SALARIED_FT` 360, `HOURLY_FT` 8, `TEMP` 5, `CONTRACTOR` 4
Pay	165 of 377	159 of the 207 in the United States; none of the 92 in India or the 37 in Ireland
Created date	377 of 377	110 created in October 2026 and 87 in September; the oldest still open dates from July 2023

Pay is often more than one range. 43 of the 165 postings with pay give two or more, 38 of them split by pay tier, and one gives four. 163 are yearly and 2 monthly, and the currencies are US and Canadian dollars, Costa Rican colones, Brazilian reais and Mexican pesos.

Where a script stops

A full read costs a request per posting, because the date and the pay live only in the record: 378 requests for 377 postings here.
Nothing says what changed. The list carries no timestamp, so you keep the last read, compare, and decide what counts as new, changed or gone.
Pay by tier needs a rule: which range is "the" salary, or a column that keeps them all.

We publish a Rippling jobs scraper on the Apify Store that starts from the board's slug. It reads the list first and asks for a record only for a posting it will save, and in incremental mode it returns, and charges for, only the postings whose title, department, places or work arrangement changed since its last run. The price of that saving is that an edit only to a posting's text, pay, employment type or date is not reported as a change. The full reference page has the earlier measured runs.

Disclosure: Adderley Data, who wrote this, builds and sells that Actor; neither link carries a referral or affiliate code. We are not affiliated with Rippling, and "Rippling" is used only to say which job boards this describes. No field in either endpoint's answer names a recruiter or a hiring manager, and the Actor has no field for a person's name, email or phone.

The Workday job board API, measured: 20 a page, a 2,000 cap and an offset that loops

Adderley Data — Thu, 22 Oct 2026 18:38:18 +0000

Workday does not publish a public job board API. Every careers site on myworkdayjobs.com still fills its job list from JSON: the visitor's browser sends a POST to an endpoint under /wday/cxs/, and that endpoint is what people find when they search for a Workday jobs API.

We read it every day, so here is how it behaves: the request, the paging rules, the filters, the posting record and the errors. Unless a line gives another date, each behaviour below was checked against Workday's own careers site on 23 October 2026.

Three names from the careers link

Everything comes from the link to a company's careers site:

https://acme.wd5.myworkdayjobs.com/External

tenant: acme, the company's Workday tenant;
host: wd5, one of several numbered data centres (wd1, wd5, wd12 and others);
site: External, the name the company gave this careers site. A company can run several.

Links often carry a language code, such as /en-US/External. Leave it out of the API path: with it, the endpoint answers HTTP 405.

There is no public lookup from a company's name to these three, so you start from the link on its careers page.

The list request

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

The answer has four keys: total, jobPostings, facets and userAuthenticated. A posting in the list is thin, six keys and nothing more:

{
  "title": "Data Engineer",
  "externalPath": "/job/Melbourne/Data-Engineer_JR-0001042",
  "locationsText": "Melbourne",
  "postedOn": "Posted 3 Days Ago",
  "remoteType": "Flex",
  "bulletFields": ["JR-0001042"]
}

postedOn is relative text that stops at "Posted 30+ Days Ago", and locationsText turns into a count ("2 Locations") when a role has several. The date, the country, the time type and the text are in each posting's own record, further down.

searchText is the careers page's own search box; an empty string returns everything.

The paging rules

Four things to know before you write the loop:

20 a page at most. A limit of 21 or more answers HTTP 400.
Only the first page reports total. Later pages answer "total": 0, so read it once and keep it.
An offset past the end loops back. It does not return an empty page: on a site listing 387 roles, offset 400 returned the same 20 postings as offset 0. A loop that waits for an empty page never ends, so stop at the first page's total.
The tenant is case-sensitive. In capitals, the endpoint answered 502. The site name is not: workday and Workday both returned 387.

A script that follows those rules, for Node 18 or later and nothing to install:

// list-workday-jobs.mjs: every open role on one Workday careers site (Node 18 or later)
// node list-workday-jobs.mjs https://acme.wd5.myworkdayjobs.com/External
const careersUrl = new URL(process.argv[2]);
const tenant = careersUrl.hostname.split('.')[0];
// The site name is the last part of the path, after any language code such as en-US.
const site = careersUrl.pathname.split('/').filter((part) => part && !/^[a-z]{2}-[A-Z]{2}$/.test(part)).pop();
const listUrl = `https://${careersUrl.hostname}/wday/cxs/${tenant}/${site}/jobs`;
const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

async function listPage(offset) {
  const response = await fetch(listUrl, {
    method: 'POST',
    headers: { 'content-type': 'application/json', accept: 'application/json' },
    body: JSON.stringify({ appliedFacets: {}, limit: 20, offset, searchText: '' }),
  });
  if (!response.ok) throw new Error(`HTTP ${response.status} for offset ${offset}`);
  return response.json();
}

const first = await listPage(0);
const total = first.total; // only the first page says how many there are
if (total >= 2000) console.warn('This board is at the 2,000 cap: read it one filter value at a time.');
const postings = [...first.jobPostings];
for (let offset = 20; offset < Math.min(total, 2000); offset += 20) {
  await sleep(700); // one request at a time, under 90 a minute
  postings.push(...(await listPage(offset)).jobPostings);
}
console.log(`${postings.length} postings, total ${total}`);
for (const posting of postings.slice(0, 3)) console.log(posting.title, '|', posting.locationsText, '|', posting.externalPath);

Run against Workday's own careers site, with and without /en-US/ in the link, it printed 387 postings, total 387 both times, in about a minute. Keep the pause: these are a company's careers pages, and one request at a time is plenty.

The 2,000 cap, and reading past it

total stops at 2,000. On 24 September 2026, a board whose filter counts added up to 2,616 reported a total of 2,000, and paging cannot reach the rest.

The way past it is the careers page's own filters. Each entry in facets lists values with an id and a count:

{
  "facetParameter": "jobFamilyGroup",
  "descriptor": "Job Category",
  "values": [
    { "descriptor": "Engineering", "id": "a1b2c3d4e5f60718293a4b5c6d7e8f90", "count": 112 }
  ]
}

Put a value's id back in appliedFacets and the list narrows to it:

{ "appliedFacets": { "jobFamilyGroup": ["a1b2c3d4e5f60718293a4b5c6d7e8f90"] }, "limit": 20, "offset": 0, "searchText": "" }

On Workday's own site, the country filter for the United States narrowed 387 roles to 188, which is its count. Two things to watch when you split a large board:

Pick a filter whose values each sit under 2,000, and split a value again if one does not.
Some filters overlap. Workday's own site has seven: remote type, country, job category, state, time type, distance and a location group. Its job category counts add up to the total (387); its country counts add up to 416, because a role in several countries is counted under each. Split by country and you must remove duplicates by externalPath.

The posting record

Each posting's externalPath gives its own record with a GET:

curl "https://acme.wd5.myworkdayjobs.com/wday/cxs/acme/External/job/Melbourne/Data-Engineer_JR-0001042"

The posting sits under jobPostingInfo:

startDate: the day the posting went up (2026-10-22 on the record read), and endDate where the company has set a closing date (2026-10-29 on the same record). They are the only absolute dates in either response.
timeType: the company's own words, such as "Full Time".
location and additionalLocations: every location label, as the company writes it.
jobRequisitionLocation.country.alpha2Code: the ISO country code (US). country beside it has only a name and Workday's internal id.
jobDescription: the whole posting as HTML; the record read on 23 October ran to 11,236 characters.
jobReqId, remoteType, externalUrl and Workday's internal ids.

Beside jobPostingInfo, hiringOrganization.name names the employing entity, such as "Workday, Inc.". Two things are absent: there is no pay field (where a company states pay, it is inside jobDescription, in its own words), and neither response names a recruiter.

The errors you will meet

You sent	Workday answered
`limit` of 21 or more	HTTP 400
a language code in the path (`/wday/cxs/acme/en-US/External/jobs`)	HTTP 405
the wrong `wd` host, or a tenant that does not exist	HTTP 422
a site name that does not exist	HTTP 404, `"errorCode": "S21"`, `"not found: Job_Posting_Site_ID=…"`
the tenant in capitals	HTTP 502

All five were checked on 23 October 2026. The 502 is the one that misleads, because it reads like an outage: check the tenant's case before you retry.

What a whole board costs

One list page per 20 postings, plus one record per posting for anything beyond title, location label and relative date. On 1 October 2026, Workday's own careers site listed 362 roles in 24 countries. Reading all of it took 381 requests (19 list pages and 362 records), every one answered at the first attempt, in 4 minutes 21 seconds at 90 requests a minute. 235 of the 362 stated a pay range in their text.

Where a script stops

Reading one board once is the script above plus a loop over the records. Watching boards over time is where the work is:

Every full read costs a request per posting, because the list holds no date, country or text.
Nothing says what changed. You keep yesterday's postings, compare, and decide what counts as new, changed or gone. An edit to a posting's text alone does not show in the list.
Large boards need splitting past the cap, and the filters overlap.

We publish a Workday jobs scraper on the Apify Store that does this from the careers link: it pages and splits as above and, in incremental mode, reads a record only for a role the list shows is new or changed, then returns, and charges for, only the roles that changed since its last run. The full reference page has the measured run behind the cost figures.

Disclosure: Adderley Data, who wrote this, builds and sells that Actor; neither link carries a referral or affiliate code. We are not affiliated with Workday, and "Workday" is used only to say which careers sites this describes. The endpoint names no recruiter, and the Actor has no field for a person's name, email or phone.