praxyjobs

Workday Job API: A Practical Guide to Employer Career-Site Data

Workday powers recruiting for many large employers, but there is no single public endpoint that lists every Workday customer. Each employer runs a tenant-specific Candidate Experience site with its own identifiers and job inventory. Building reliable coverage therefore requires both tenant discovery and disciplined synchronization.

8 min read · Updated July 2026

How public Workday career sites are structured

A Workday Candidate Experience URL typically identifies the employer tenant, a site name, and a regional host. The site's frontend calls public CXS endpoints to search requisitions and load individual job details.

Those requests do not require a candidate login, but the identifiers must match the employer's actual career site. Guessing tenant and site combinations produces false negatives and unnecessary traffic.

Search and detail are separate operations

The search response is designed for cards and pagination. It contains enough information to discover requisitions but not always the complete description and metadata required by a downstream product.

A typical collector first paginates the search endpoint, then requests the detail payload for each discovered job. Concurrency must remain bounded because a large employer can publish thousands of roles.

POST /wday/cxs/{tenant}/{site}/jobs
GET  /wday/cxs/{tenant}/{site}/job/{externalPath}

Normalize without erasing provenance

Map titles, descriptions, locations, requisition identifiers, and posting dates into your common schema. Preserve the Workday tenant, site, external path, and canonical employer URL so every normalized record can be checked against its origin.

Do not invent salary, remote status, or employment type when the source does not publish them. Missing values are more trustworthy than confident guesses in candidate-facing products.

Detect changes and closures

A requisition disappearing from a single page is not enough to call it closed; pagination shifts as jobs are added and removed. Complete the scheduled tenant scan, then compare the observed identifier set with the previous successful scan.

Use a grace window for transient failures and only advance the tenant checkpoint after the scan succeeds. This prevents an incomplete run from expiring a large employer's entire inventory.

  • Checkpoint successful scans
  • Track first-seen and last-seen timestamps
  • Retry bounded failures
  • Expire only after a complete comparison
  • Keep the direct employer apply URL

Use Workday alone or through a unified API

A dedicated Workday connector can be appropriate when your product targets a known employer set and needs Workday-specific fields. A unified ATS API is simpler when Workday is one of many sources and the product needs consistent search and lifecycle behavior.

Praxy Jobs exposes Workday alongside dozens of other ATS platforms through one schema, while retaining Workday source metadata on every result.