Every source we index, in the open.

Workday runs hiring for a large share of the world's biggest employers. Each tenant exposes its career site through per-tenant CXS endpoints on myworkdayjobs.com, which we page through with rate-limited, politeness-first pacing to collect every posted requisition. List responses carry title, locations, and posted-on dates but not the description body, so Workday jobs in our index link out to the company's own site for the full spec rather than carrying a guessed description.

how we index workday →

SmartRecruiters publishes each customer's postings through a free public API, paginated with limit and offset. We collect every active posting with its title, location, and released date, and link to the company's own apply page. The listing payload does not include the description body, so SmartRecruiters jobs carry structured fields and a direct apply link rather than a scraped description.

how we index smartrecruiters →

Greenhouse is the ATS of choice for a huge share of startups and scale-ups, and it publishes every public board through a free JSON API. We fetch each company's board from the official boards API with content enabled, so titles, departments, offices, and the full job description arrive in a single request — no HTML scraping involved. Posting timestamps come straight from the API; salary appears only when the employer writes it into the posting itself.

how we index greenhouse →

ADP Workforce Now runs payroll and hiring for a very large share of US employers, and its Career Center publishes requisitions through a public JSON endpoint per tenant. We page through that endpoint directly — titles, locations, posting dates, and the requisition description all arrive in the listing payload. Apply links go to the company's own ADP Career Center.

how we index adp workforce now →

iCIMS runs career portals for many large enterprises, typically on a careers subdomain of the company's own website. We index the public portal pages with rate-limited, politeness-first pacing, preferring schema.org JobPosting JSON-LD where the tenant exposes it and falling back to the public job-card listings. Fields vary by tenant: titles, locations, and apply URLs are reliable; descriptions and salary appear only where the portal publishes them.

how we index icims →

Paycom career portals are React apps backed by a native JSON API, and we call that API directly instead of scraping the rendered page. Listings arrive paginated with titles and locations, and a small, budgeted number of per-job detail fetches fill in descriptions each sweep. Apply links go to the company's own Paycom portal.

how we index paycom →

Dayforce hosts recruiting for many large employers and publishes a public job feed per tenant. We read each tenant's feed endpoint directly and surface only what the feed actually contains — core structured fields like title and location — with the apply link pointing at the company's own Dayforce careers site.

how we index dayforce →

Workable powers thousands of SMB and startup career pages, and its widget API lists every published job for an account without auth. We read titles, locations, and remote flags from that JSON and link straight to the hosted apply page. Description bodies are not part of the widget listing, so we don't fabricate them.

how we index workable →

Oracle Fusion Cloud HCM candidate-experience sites expose a public requisitions API — the same one the career site itself calls. We use that native API per tenant to list requisitions with titles, locations, and posting metadata, then link to the company's own candidate-experience site to apply.

how we index oracle cloud hcm →

UKG Pro (formerly UltiPro) hosts recruiting boards on recruiting.ultipro.com for many large employers. Each board backs its UI with a public search endpoint that we call directly, paging through results with rate-limited, politeness-first pacing. Postings carry titles, locations, posted dates, and descriptions where the board exposes them; apply links go to the company's own UKG board.

how we index ukg pro recruiting →

Paylocity hosts recruiting boards at recruiting.paylocity.com, and each public board page embeds its full listing data as JSON. We parse that payload directly rather than scraping rendered HTML, and fetch a small, budgeted number of detail pages per sweep to fill in job descriptions. Titles and locations come from the board payload; salary appears when the employer publishes it.

how we index paylocity →

Lever hosts public postings for each customer at a stable JSON endpoint. One request per board returns every published role with full description, team, location, commitment, and creation timestamp, plus the hosted apply URL we link you to directly. It is one of the cleanest sources in the index: structured, complete, and straight from the company's own board.

how we index lever →

Eightfold powers AI-driven career sites for large enterprises on eightfold.ai subdomains. The site's own public search API returns postings as structured JSON, which we page through per tenant with rate-limited, politeness-first pacing. Titles, locations, and posting metadata are consistent; the search payload does not carry description bodies, so we link out for the full spec rather than guessing.

how we index eightfold →

Ashby is a newer ATS popular with fast-growing, engineering-heavy startups, and it ships a public posting API for every hosted job board. A single JSON response carries each role's full description, department, location, remote flag, and publish date. Compensation shows up when the employer chooses to publish it on their board, and we pass it through as-is.

how we index ashby →

Breezy HR publishes each company's open positions as a public JSON feed on the company's own breezy.hr subdomain. We read the feed directly — titles, locations, full descriptions, and published dates — and link to the hosted application page.

how we index breezy hr →

Cornerstone (CSOD) career sites expose a public search endpoint that the site's own UI calls. We query it per tenant with a deliberately small page budget per sweep, collecting titles, locations, descriptions, and posting-effective dates, and link to the native requisition page.

how we index cornerstone →

BambooHR gives every customer a hosted careers page backed by a public JSON listing on the company's own subdomain. One request returns the open positions with title, department, location, and the description the employer wrote. It is a common home for small and mid-size company hiring, and one of the simplest, most reliable feeds we index.

how we index bamboohr →

Recruitee exposes every public careers site through a clean offers API on the company's own subdomain. A single request lists all open roles with descriptions, requirements, and location data. We fetch it directly and link to the native apply page.

how we index recruitee →

Personio is the dominant HR platform for European small and mid-size companies, and every hosted careers page ships a public XML feed. We parse the feed per company — titles, departments, offices, full descriptions, and creation dates — and link candidates to the company's own Personio job page.

how we index personio →

Jobvite hosts public boards at jobs.jobvite.com. We index each board's public pages, preferring schema.org JobPosting JSON-LD when present and falling back to the board's job links. Titles and canonical apply URLs are consistent; descriptions come through where the structured data provides them.

how we index jobvite →

Rippling ATS boards expose a public jobs API per board. We fetch the full listing in one pass — titles, locations, descriptions, and posted dates — and link to the company's own Rippling job page.

how we index rippling →

Taleo career sections still run hiring for many large, established employers. We index the public requisition pages per tenant, using schema.org JSON-LD when the site provides it and the native requisition listings otherwise. Fields vary with each tenant's configuration — we surface what the career section actually publishes and nothing more.

how we index oracle taleo →

Teamtailor hosts branded career sites on teamtailor.com subdomains, popular with European startups and scale-ups. We index the public jobs pages, reading schema.org JobPosting JSON-LD where present and the job-card links otherwise, and send applicants to the company's own listing. Titles and apply URLs are consistent; descriptions come through where the structured data provides them.

how we index teamtailor →

JazzHR customers host public boards on applytojob.com. We index the public listing pages directly, collecting each posting's title, location, and native apply link; description bodies are not part of the listing, so we link through rather than invent them.

how we index jazzhr →

Zoho Recruit career sites publish openings through a public endpoint backing the hosted careers page. We fetch it per company — titles, locations, descriptions, and opening dates — and link to the native listing.

how we index zoho recruit →

HiBob careers pages are backed by a public job-ad JSON endpoint per company. We read it directly — titles, locations, descriptions, and published dates — and link candidates to the company's own hosted listing.

how we index hibob →

Trakstar Hire (formerly Recruiterbox) serves public openings through a free frontend API. We read it per company — titles, locations, and full descriptions — and link to the hosted application page.

how we index trakstar hire →

Keka is a widely used Indian HR platform whose hosted career pages back onto a public active-jobs JSON endpoint. We read that endpoint per company — titles, locations, published dates, and the description text the employer wrote — and link to the native Keka job page.

how we index keka →

Pinpoint publishes each customer's board through a public JSON endpoint. We fetch it per tenant — titles, locations, descriptions, and published dates — and link to the native job page.

how we index pinpoint →

Dover boards resolve through a public slug lookup plus a careers-page jobs API. We use both to list each company's open roles — titles, locations, and canonical apply URLs; the listing payload does not include description bodies, and we never fabricate them.

how we index dover →

PyjamaHR career pages are served by a public JSON API, paginated per company. We fetch it directly — titles, locations, descriptions, and published dates — and link to the company's hosted listing.

how we index pyjamahr →

Deel hosts job boards for companies hiring through its global employment platform. We index each board's public pages via the schema.org JobPosting JSON-LD they embed, so every field comes exactly as published, and link to the original posting.

how we index deel →

Not a single ATS — this is our catch-all for companies whose own careers pages embed schema.org JobPosting structured data. We read the JSON-LD directly from the company's site, so every field comes exactly as the employer published it, and the apply link is the company's own page.

how we index first-party careers pages →

SAP SuccessFactors career sites power hiring at many global enterprises. We index each company's own career-site search pages — the first-party site, not a copy — walking the public search results with rate-limited, politeness-first pacing. Titles, locations, and requisition links are dependable; the search results do not carry description bodies, so we link to the tenant's own posting for the full spec.

how we index sap successfactors →

Darwinbox powers HR and hiring at many Indian and Southeast Asian enterprises. We index each company's careers site through its public candidate API — titles, locations, descriptions, and posting dates — and link to the native listing to apply.

how we index darwinbox →

Phenom builds first-party career sites for large enterprises, so the jobs live on the company's own domain. Those pages eager-load their search results as embedded JSON, which we parse straight from the page source. That gives us titles, locations, and canonical job URLs exactly as the company's site publishes them.

how we index phenom →

Paycor Recruiting (formerly Newton) hosts public CareerHome boards per customer. We read the public board pages for structured listing data and make limited, budgeted detail-page fetches to pick up descriptions. Everything links back to the company's own board to apply.

how we index paycor recruiting →

Zwayam careers sites are backed by a public search API, which we query per company using the identifiers the site itself embeds. Postings carry titles, locations, descriptions, and creation dates, and link back to the company's own careers portal.

how we index zwayam →