Why Workday job boards need a separate adapter

It is an employer-site problem, not only a provider problem

A URL on myworkdayjobs.com identifies Workday as the likely platform, but that host match alone does not identify the employer's usable job feed. The hostname and path still need to resolve to the correct tenant and career site.

For a supported URL such as example.wd10.myworkdayjobs.com/Example_Careers, BD Engine derives:

• the tenant from the hostname,
• the career-site identifier from the URL path, and
• the public jobs endpoint under /wday/cxs/{tenant}/{site}/jobs.

Recognition is not retrieval. Seeing myworkdayjobs.com in a URL is enough to classify the likely ATS. It is not enough to promise that the tenant, site, endpoint, and every current role will resolve successfully.

What the adapter does

1. Parse the public URL. The current adapter accepts the supported {tenant}.wd{number}.myworkdayjobs.com hostname pattern.
2. Derive the career site. It reads the relevant path segment, including supported locale-prefixed paths and existing /wday/cxs/ endpoints.
3. Request jobs in pages. The adapter posts to the public jobs endpoint in batches, using the reported total to determine the remaining offsets within a bounded page limit.
4. Normalize the records. Returned fields are mapped into a consistent title, location, source URL, and lifecycle shape used by the workspace.
5. Retry specific transient failures. A temporary HTML or challenge response from a Workday host is treated as retryable rather than as valid job data.

Why a Workday board can still fail

• Custom hostnames: An employer can place its career experience behind a domain that does not expose the standard Workday pattern.
• Renamed career sites: A tenant can have more than one site or change the path used by the public board.
• Transient challenges: A request can receive HTML, a waiting page, or another non-JSON response even when the endpoint normally works.
• Incomplete pagination: Later pages can fail after an initial response succeeds; a reliable workflow should surface that partial failure.
• Role lifecycle changes: A role can be removed or changed after it was retrieved. The employer's current posting remains the source of truth.

A practical verification checklist

1. Keep the original employer career-site URL beside every imported role.
2. Confirm that the role still opens on the employer's site before applying or requesting a referral.
3. Record the last successful refresh instead of implying continuous freshness.
4. Keep unresolved sites visible for review rather than treating them as zero jobs.
5. Ask for the exact failing URL when troubleshooting; the tenant and career-site path matter.