DEV Community: UDANINN

You can tell which ATS a company uses by looking at its careers URL

UDANINN — Sat, 15 Aug 2026 14:27:49 +0000

Every job-data project starts with the same question: this company has a careers
page, but what is actually behind it?

You do not need to guess. Seven of the most common applicant tracking systems put
their identity directly in the URL, and each one has a public JSON endpoint you
can derive from that same URL. Here is the mapping, plus the parts that bite.

The lookup table

You see	ATS	Public JSON
`boards.greenhouse.io/acme` or `job-boards.greenhouse.io/acme`	Greenhouse	`boards-api.greenhouse.io/v1/boards/acme/jobs`
`jobs.lever.co/acme`	Lever	`api.lever.co/v0/postings/acme?mode=json`
`jobs.ashbyhq.com/acme`	Ashby	`api.ashbyhq.com/posting-api/job-board/acme`
`apply.workable.com/acme`	Workable	`apply.workable.com/api/v1/widget/accounts/acme`
`acme.recruitee.com`	Recruitee	`acme.recruitee.com/api/offers/`
`careers.smartrecruiters.com/acme`	SmartRecruiters	`api.smartrecruiters.com/v1/companies/acme/postings`
`acme.wd5.myworkdayjobs.com/Careers`	Workday	see below - this one is different

If you would rather not maintain the detection logic and the per-platform
quirks below, it is packaged as a hosted scraper that does the detection for you:
ATS Jobs & Hiring Signals, callable from
Python or JavaScript.

Six of the seven are a straight substitution: pull the company token out of the
URL, drop it into the API pattern, get JSON. No key, no proxy, no browser.

Workday is the one that breaks the pattern

Every other ATS needs one identifier. Workday needs three, and only one of them
is guessable:

https://acme.wd5.myworkdayjobs.com/External_Career_Site
         ^^^^  ^^^                  ^^^^^^^^^^^^^^^^^^^
       tenant  shard                site

tenant is usually the company name, so you might guess it
shard is wd1 through wd12 or higher, assigned when the account was provisioned. There is no pattern
site is free text chosen by whoever set it up. External_Career_Site, NVIDIAExternalCareerSite, Careers are all real

This is why "just build the Workday URL from the company name" does not work.
You need a real link from the company's careers site - any link, a single job
posting is enough, because all three parts are in it.

The endpoint itself is:

POST https://{tenant}.{shard}.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs
Content-Type: application/json

{"appliedFacets": {}, "limit": 20, "offset": 0, "searchText": ""}

Three things that will waste your afternoon

Workday pages at exactly 20. Ask for limit: 21 and you get HTTP 200 with an
empty list and total still filled in. That looks identical to a company with no
openings, so you conclude the board is empty and move on. Always page at 20.

Workday's postedOn is a display string, not a date. It returns
"Posted Today", "Posted 3 Days Ago", "Posted 30+ Days Ago" - and it returns
them in whatever locale the endpoint feels like. Pin Accept-Language: en-US on
every request or your date parsing silently rots. Note also that 30+ carries no
date at all, so anything older than a month has no usable timestamp.

Greenhouse's jobs list has no departments. /jobs gives you titles and
locations; departments live on a separate endpoint. If you need both you have to
join them yourself, which is the single most common thing people miss.

Detecting it in code

import re

PATTERNS = [
    ("greenhouse",      r"(?:job-)?boards\.greenhouse\.io/([\w-]+)"),
    ("lever",           r"jobs\.lever\.co/([\w-]+)"),
    ("ashby",           r"jobs\.ashbyhq\.com/([\w-]+)"),
    ("workable",        r"apply\.workable\.com/([\w-]+)"),
    ("recruitee",       r"([\w-]+)\.recruitee\.com"),
    ("smartrecruiters", r"careers\.smartrecruiters\.com/([\w-]+)"),
]

WORKDAY = re.compile(r"([\w-]+)\.(wd\d+)\.myworkdayjobs\.com(?:/([^?#\s]*))?", re.I)
LOCALE = re.compile(r"^[a-z]{2}(-[A-Za-z]{2,4})?$")


def detect(url: str):
    m = WORKDAY.search(url)
    if m:
        tenant, shard = m.group(1).lower(), m.group(2).lower()
        segs = [s for s in (m.group(3) or "").split("/") if s]
        site = None
        # The cxs API URL carries the site one segment after the tenant.
        if len(segs) >= 4 and segs[0].lower() == "wday" and segs[1].lower() == "cxs":
            site = segs[3]
        else:
            for seg in segs:            # skip locale segments like en-US
                if LOCALE.match(seg):
                    continue
                site = seg
                break
        return {"ats": "workday", "tenant": tenant, "shard": shard, "site": site}

    for ats, pattern in PATTERNS:
        m = re.search(pattern, url, re.I)
        if m:
            return {"ats": ats, "token": m.group(1)}

    return None

That locale loop matters more than it looks. Workday URLs shared from a
non-English browser carry /en-US/ or /fr-CA/ before the site name, and if you
take the first path segment blindly you get site="en-US" and an endpoint that
404s on every request. Walking past locale segments also means a deep link to a
single posting works as input, which is usually the only link you can get someone
to send you.

Verified against these:

nvidia.wd5.myworkdayjobs.com/NVIDIAExternalCareerSite
  -> nvidia / wd5 / NVIDIAExternalCareerSite
acme.wd3.myworkdayjobs.com/fr-CA/External_Career_Site/job/Montreal/Dev_JR1
  -> acme / wd3 / External_Career_Site
salesforce.wd12.myworkdayjobs.com/wday/cxs/salesforce/External_Career_Site/jobs
  -> salesforce / wd12 / External_Career_Site

Why bother

Once you can identify the ATS from a URL, "monitor hiring at these 200 companies"
stops being 200 scrapers and becomes one dispatcher plus seven thin clients. A
company that is hiring is a company that is spending, which is why this data is
worth having in the first place - headcount changes are one of the earliest
public signals that a budget exists.

I packaged each of these as a scraper on Apify, one per platform plus a combined
one that auto-detects:

Platform	Actor
All six, auto-detected	ATS Jobs & Hiring Signals
Greenhouse	Greenhouse Jobs Scraper
Lever	Lever Jobs Scraper
Ashby	Ashby Jobs Scraper
Workable	Workable Jobs Scraper
Recruitee	Recruitee Jobs Scraper
SmartRecruiters	SmartRecruiters Jobs Scraper
Workday	Workday Jobs Scraper

The endpoints above are public either way - if you only need one board, the curl
is genuinely all it takes.

Earlier posts with the full field-by-field breakdown:
the six open JSON boards
and Workday's hidden API.

Workday job boards have a JSON API too. It's just better hidden.

UDANINN — Tue, 11 Aug 2026 13:21:35 +0000

In the last post
I listed six ATS platforms whose job boards are open JSON APIs — Greenhouse,
Lever, Ashby, Workable, Recruitee, SmartRecruiters. The honest caveat at the
bottom was that none of it covers Workday, which is where most of the Fortune
500 actually lives.

This post closes that gap. Workday careers sites are also a client-side app
calling a JSON API, and you can call it directly — no key, no login, no
headless browser. It is just harder to find, shaped differently, and mined
with quieter traps than any of the six easy ones.

Everything below was run live while writing this, in August 2026: NVIDIA
(2,000 open roles), Salesforce (1,477), Adobe (800). As before, the counts are
there to show the response shape, not as figures to check against later.

The endpoint

Workday careers pages live at URLs like:

https://{tenant}.wd{N}.myworkdayjobs.com/{site}

Behind each one is a POST endpoint:

POST https://{tenant}.wd{N}.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs
Content-Type: application/json

{"appliedFacets": {}, "limit": 20, "offset": 0, "searchText": ""}

Real examples, all verified today:

nvidia.wd5.myworkdayjobs.com     /wday/cxs/nvidia/NVIDIAExternalCareerSite/jobs   → 2,000 roles
salesforce.wd12.myworkdayjobs.com/wday/cxs/salesforce/External_Career_Site/jobs   → 1,477 roles
adobe.wd5.myworkdayjobs.com      /wday/cxs/adobe/external_experienced/jobs        →   800 roles

Note it is a POST with a JSON body, unlike every endpoint in the previous
post. A GET returns nothing useful, which is one reason people conclude the
API "doesn't exist" and reach for Selenium.

Everything below is the method, so you can build this yourself. If you would
rather not own the maintenance, I packaged it as a hosted scraper —
Workday Jobs Scraper, callable from
Python or JavaScript.
Either way, the traps below are worth reading, because they are the same three
that will bite your own implementation.

Finding the three parts

With Greenhouse you can guess the board token from the company domain.
With Workday you cannot guess any of the three parts:

{tenant} is usually the company name, but not reliably
wd{N} is a shard number — NVIDIA is on wd5, Salesforce on wd12 — and there is no rule for which
{site} is whatever the company named their career site: NVIDIAExternalCareerSite, External_Career_Site, external_experienced. Three companies, three naming conventions.

The good news: every Workday job link contains all three. Take any posting
URL a company shares —

https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCareerSite/job/...

— and you can read tenant (nvidia), shard (wd5) and site
(NVIDIAExternalCareerSite) straight out of it, dropping the locale segment
(en-US) if present. So the practical flow is: given a company, find one job
link (their careers page, a LinkedIn posting, a Google result), decompose it
once, and you have the API forever.

Trap 1: `limit` above 20 returns zero rows, not an error

This one cost me the most time, and I have not seen it written down anywhere.
The endpoint pages at 20 records. If you ask for more:

{"limit": 20}  → 20 jobs
{"limit": 21}  → 0 jobs
{"limit": 100} → 0 jobs

No error, no warning, HTTP 200, total still says 1,477 — and an empty
jobPostings array. If your code asks for 100 per page (a perfectly normal
thing to do, since SmartRecruiters takes 100), every Workday company comes
back as "not hiring". Silent wrong answers again: the response looks exactly
like a company with no openings.

Page with limit: 20 and step offset by 20 until you reach total:

import httpx

def workday_jobs(tenant: str, shard: str, site: str) -> list[dict]:
    url = f"https://{tenant}.{shard}.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs"
    out, offset = [], 0
    with httpx.Client(timeout=30) as client:
        while True:
            r = client.post(url, json={
                "appliedFacets": {}, "limit": 20,
                "offset": offset, "searchText": "",
            }, headers={"Accept-Language": "en-US"})
            r.raise_for_status()
            data = r.json()
            batch = data.get("jobPostings") or []
            out.extend(batch)
            offset += 20
            if not batch or offset >= data.get("total", 0):
                return out

Trap 2: `postedOn` is not a date — it is a sentence, in your language

The list response carries five fields per job:

title, externalPath, locationsText, postedOn, bulletFields

postedOn looks like a date field. It is a localized display string. The
same Salesforce posting, same endpoint, different Accept-Language:

Accept-Language: en-US  →  "postedOn": "Posted Today",   "locationsText": "2 Locations"
Accept-Language: ko     →  "postedOn": "오늘 공고",        "locationsText": "2개 근무지"

I only caught this because my browser is set to Korean. If you parse
postedOn as a date, your code works on your machine and breaks for anyone
whose locale differs — or breaks next week when "Posted Today" becomes
"Posted 30+ Days Ago", which is the only granularity you get past a month.

Two consequences: always send an explicit Accept-Language, and if you need a
real date, get it from the detail endpoint below (startDate is an actual
YYYY-MM-DD).

The detail endpoint

Each list item has an externalPath. Append it to the site base with an
Accept: application/json header:

GET https://{tenant}.wd{N}.myworkdayjobs.com/wday/cxs/{tenant}/{site}{externalPath}
Accept: application/json

That returns the full record: jobDescription (HTML), timeType
("Full time"), startDate (a real date at last), jobReqId, country,
additionalLocations. Without the Accept header you get the HTML shell of
the careers page instead — the same URL serves both.

One request per job, so for a 2,000-role tenant that is 2,000 extra requests.
Fetch details only for the postings you actually care about, after filtering
the list.

Trap 3: no CORS — this is server-side only

The six platforms in the previous post mostly tolerate browser calls; Workable
even sends explicit CORS headers. Workday does not. A cross-origin fetch
from a browser dies before you see a status code. Call it from a server, a
script, a notebook — anything but someone else's web page. (Same-origin works,
which is how the careers page itself uses it.)

Limits, honestly

This is the API behind the public careers page, read-only and unauthenticated — but unlike Greenhouse's boards API it is not documented as a public contract. Workday can reshape it without notice. Build accordingly: tolerate missing fields, alert on shape changes.
The list response is thin — five fields. Department, salary and employment type all live behind the per-job detail request.
Some tenants run heavily customized sites; the three above are typical, not universal.
Page politely. It is one POST per 20 jobs; there is no reason to hammer it.

Update: it is built now

I went ahead and packaged this as a ready-to-run scraper:
Workday Jobs Scraper & API on Apify —
paste any careers or job-posting URL and it decomposes tenant, shard and
site itself, pages at the mandatory 20, pins Accept-Language: en-US, and
returns the same normalised schema as the six easy platforms.

For one company you should still just use the code above - it is a single
loop. The Actor earns its keep at the point where that stops being true:
many tenants, change detection, schedules.

Six ATS platforms publish their job boards as open JSON. Here are the endpoints.

UDANINN — Mon, 10 Aug 2026 12:12:40 +0000

Most "job scraping" tutorials teach you to render a careers page in a headless
browser and pick apart the HTML. For the majority of company career pages, that
is unnecessary. The page you are trying to scrape is itself a client-side app
calling a public JSON API — and you can call that API directly.

No key. No proxy. No anti-bot. Just JSON.

Below are the six applicant tracking systems that cover most of the startup and
mid-market hiring world, the exact endpoint each one exposes, and the traps I
hit building against all six.

Every endpoint here was run live while writing this, in August 2026. The job
counts are from that run and will have drifted by the time you read it — they
are there to show the shape of the response, not as figures to check against.

Why the APIs are open in the first place

When a company buys Greenhouse or Lever, they get a hosted job board, and they
usually want the openings to appear on their own marketing site under their own
design. So the ATS ships a public read API for exactly that purpose.

That is the important bit: this is not an oversight to be exploited. The
endpoint exists to be read by third parties. It is documented, versioned, and
stable — the same properties that make it pleasant to build on.

The practical consequence is that reading job data is one of the few remaining
corners of the web where you do not need a proxy budget.

The six endpoints

Greenhouse

GET https://boards-api.greenhouse.io/v1/boards/{token}/jobs

The token is the slug in job-boards.greenhouse.io/{token}. stripe returns
around 550 openings.

The trap: the /jobs response has no department on it at all — the keys are
absolute_url, data_compliance, internal_job_id, location, metadata, id, updated_at, requisition_id, title, company_name, first_published, language, application_deadline, and that is the whole list. If you want departments you
have to call a second endpoint and join:

GET https://boards-api.greenhouse.io/v1/boards/{token}/departments

Each department carries its own jobs array, so you build an id → department
map and merge. Miss this and every record silently comes back with an empty
department, which looks like the companies just didn't fill it in.

Lever

GET https://api.lever.co/v0/postings/{token}?mode=json

leverdemo is Lever's own sandbox board and returns 388 postings, which makes
it a good fixture.

The trap: Lever returns createdAt as epoch milliseconds, while
Greenhouse and Ashby return ISO 8601 strings. If you normalise the others and
forget this one, a "posted in the last 7 days" filter doesn't error — it just
quietly returns nothing for every Lever board, because an epoch-millisecond
integer parsed as a year is not a date anywhere near today. Silent wrong answers
are worse than crashes.

Ashby

GET https://api.ashbyhq.com/posting-api/job-board/{token}

Add ?includeCompensation=true and you get published salary ranges, which
Ashby exposes far more consistently than the others — on Ramp's board, 115 of
121 postings came back with a real figure, formatted like
$211.4K – $290.6K • Offers Equity. On the other five platforms salary is the
exception rather than the rule, so if compensation data is what you are after,
Ashby boards are where it actually lives.

Workable

GET https://apply.workable.com/api/v1/widget/accounts/{token}

This is the endpoint powering Workable's embeddable widget. It gives you
department, employment type and a remote flag in one call.

Recruitee

GET https://{token}.recruitee.com/api/offers/

The trap: the response contains options_cover_letter. It is a boolean —
whether the application form asks for a cover letter. I mapped it to
employmentType at one point on nothing but name-shaped optimism, and produced
a column full of true/false where job types should have been. Read the
values, not the field names.

SmartRecruiters

GET https://api.smartrecruiters.com/v1/companies/{token}/postings?limit=100&offset=0

Two traps here, and they cost me the most time.

Pagination. The response includes totalFound, and it will happily tell you
4753 while handing you 100 records. If you don't page on offset, you silently
truncate every large employer to their first 100 openings. No error, no warning.
This is the kind of bug that survives a full test suite, because 100 records
looks like success.

Case sensitivity, and identifiers that are not the company name. The
identifier is case sensitive, and it is frequently not what you would guess:

You would guess	Result	Live identifier	Openings
`Bosch`	empty	`BoschGroup`	4,753
`Ubisoft`	empty	`Ubisoft2`	282
`Visa`	works	`Visa`	2

Note the failure mode: a wrong identifier returns HTTP 200 with an empty
list, not a 404. So "this company isn't on SmartRecruiters" and "you spelled
it wrong" are indistinguishable from the response alone. I removed Bosch from
a set of examples once, having concluded it wasn't available, when the real
answer was that I had the name wrong.

That is all six endpoints. The rest of this post is the awkward part — turning
company names into board slugs, surviving one malformed record, and polling on a
schedule. If you would rather not maintain that, it is packaged as a hosted
scraper that auto-detects the platform:
ATS Jobs & Hiring Signals, callable from
Python or JavaScript.

The thing nobody tells you: people don't have board tokens

Every one of these endpoints wants an ATS board slug. Nobody has a list of ATS
board slugs. What people actually have — sales teams, recruiters, job hunters —
is a list of company domains.

So the useful move is to accept whatever someone pastes and work it out:

def normalize_token(raw: str) -> str:
    """stripe.com, www.stripe.com and https://stripe.com/careers
    all resolve to `stripe`."""
    text = raw.strip()
    text = re.sub(r"^\w+://", "", text)
    text = re.sub(r"^www\.", "", text)
    text = text.split("/")[0]
    return text.rsplit(".", 1)[0] if "." in text else text

Then, because dropping the TLD is a guess and not a rule, keep a fallback:
shield.ai becomes shield, but the actual Lever board is shieldai (433
openings). So generate both spellings and try the second only after the first
has missed everywhere.

The cost of the fallback is one extra request on a miss. The benefit is that
users stop having to look anything up. That trade is worth it every time.

One malformed record should not cost you the other 499

Every one of these APIs will eventually hand you something you didn't expect:
jobs: null instead of an empty list, a string where a dict belongs, a null
inside an otherwise fine array. If you build each record inside a loop with no
isolation, one bad posting takes down the whole board.

def collect(items, build):
    out = []
    for raw in as_list(items):
        try:
            record = build(raw)
        except Exception:
            continue          # one bad posting, not a dead run
        if record.get("title") and str(record.get("jobUrl", "")).startswith("http"):
            out.append(record)
    return out

The title/URL check matters as much as the try block. A record with no title and
no link is not a job anyone can act on, and passing it downstream just moves the
problem somewhere it is harder to see.

Detection across all six

Given a bare company name, you can find the board by trying platforms in
sequence and stopping at the first hit. Order matters for speed — Greenhouse and
Lever cover the most companies, so put them first.

One subtlety worth getting right: a valid board with zero openings is a real
answer, not a miss. A company that genuinely isn't hiring should return an
empty list, not fall through to the next platform and eventually report "not
found". Those are different facts and users need to tell them apart.

Limits, honestly

Only these six. Companies on Taleo, iCIMS, SuccessFactors or a hand-rolled careers page are not covered by any of this.
Private or password-protected boards are not accessible, and shouldn't be.
department and team are only as good as what the company filled in.
Salary shows up only where the company published it.

The bit I'd add if you are polling this on a schedule

If you run any of this daily, diff against the previous run rather than
re-reading the whole board. Keep a snapshot of the ids you saw, and emit only
the ones that appeared and the ones that vanished. Two details that turned out
to matter:

Key the snapshot to the exact query. Change your company list or a filter and you should start a fresh baseline. Otherwise every job you simply stopped asking about gets reported as newly closed, which is a wrong answer rather than a noisy one.
A job that disappeared cannot be re-fetched. Report it from the snapshot — company, title, link — and leave the rest of the fields out instead of showing a stale copy.

If you'd rather not build it

I packaged all six adapters — normalisation, the timestamp fix, the pagination,
the domain-to-token fallback, the change detection above — as Apify Actors. You
paste company domains and get one flat schema back, exportable as
CSV/Excel/JSON or callable as an API.

Platform	Actor
All six, auto-detected	ATS Jobs & Hiring Signals
Greenhouse	Greenhouse Jobs Scraper
Lever	Lever Jobs Scraper
Ashby	Ashby Jobs Scraper
Workable	Workable Jobs Scraper
Recruitee	Recruitee Jobs Scraper
SmartRecruiters	SmartRecruiters Jobs Scraper
Workday (part 2)	Workday Jobs Scraper

Source for the adapters is on
GitHub if you just
want to read how a particular platform was handled.

But the endpoints above are the whole trick. If you only need one platform, a
40-line script will do it, and now you know which four bugs to write tests for.

Part 2 is up: Workday job boards have a JSON API too. It's just better hidden. — the enterprise ATS this post deliberately left out, with three traps that are documented nowhere else.

DEV Community: UDANINN

You can tell which ATS a company uses by looking at its careers URL

The lookup table

Workday is the one that breaks the pattern

Three things that will waste your afternoon

Detecting it in code

Why bother

Workday job boards have a JSON API too. It's just better hidden.

The endpoint

Finding the three parts

Trap 1: limit above 20 returns zero rows, not an error

Trap 2: postedOn is not a date — it is a sentence, in your language

The detail endpoint

Trap 3: no CORS — this is server-side only

Limits, honestly

Update: it is built now

Six ATS platforms publish their job boards as open JSON. Here are the endpoints.

Why the APIs are open in the first place

The six endpoints

Greenhouse

Lever

Ashby

Workable

Recruitee

SmartRecruiters

The thing nobody tells you: people don't have board tokens

One malformed record should not cost you the other 499

Detection across all six

Limits, honestly

The bit I'd add if you are polling this on a schedule

If you'd rather not build it

Trap 1: `limit` above 20 returns zero rows, not an error

Trap 2: `postedOn` is not a date — it is a sentence, in your language