Worlds / Hr and identity

Workday API

A local Workday tenant with workers, supervisory organizations, positions, time off plans and business processes. Test the agent that runs terminations, job changes and time off approvals through the right business process.

Base path: /ccx/api/v1/acme
Auth: OAuth bearer token, the world key
Endpoints: 14
Status: Active today

This reference previews the surface the Workday world serves in the closed beta. Paths mirror the public Workday API; the exact subset is confirmed when your workflow is scoped.

Connect

The run gives your agent these bindings. Keep your SDK; change only where it sends requests.

binding	meaning
`WORLDS_WORKDAY_URL`	This world's origin followed by `/ccx/api/v1/acme`
`WORLDS_API_KEY`	The world key, accepted wherever Workday expects a credential
`WORLDS_WORLD_ID`	The isolated world's identity

js · fetch

const base = process.env.WORLDS_WORKDAY_URL;

const res = await fetch(base + "/ccx/api/v1/acme/workers?limit=20", {
  headers: {
    Authorization: "Bearer " + process.env.WORLDS_API_KEY,
  },
});

const { data } = await res.json();

API reference

14 of 14

Workers

Employees and contingent workers with job, manager and status.

GET/ccx/api/v1/acme/workersList workers
GET/ccx/api/v1/acme/workers/{id}Get a worker
GET/ccx/api/v1/acme/workers/{id}/directReportsList a worker's direct reports
GET/ccx/api/v1/acme/workers/{id}/historyGet a worker's job history

Fields · 5

`id`	string	Workday id of the worker
`descriptor`	string	Display name
`primaryJob`	object	Business title, location and supervisory org
`primaryWorkEmail`	string	Work email address
`hireDate`	date	Original hire date

Time off requests

Leave and absence requests submitted by workers.

GET/ccx/api/v1/acme/workers/{id}/timeOffEntriesList time off entries for a worker
POST/ccx/api/v1/acme/workers/{id}/requestTimeOffRequest time off
GET/ccx/api/v1/acme/workers/{id}/eligibleAbsenceTypesList eligible absence types

Fields · 5

`id`	string	Request id
`worker`	object	Worker who asked for time off
`timeOffType`	object	Vacation, sick or other plan
`startDate`	date	First day off
`status`	string	Pending, approved or denied

Supervisory organizations

The org tree that workers report into.

GET/ccx/api/v1/acme/supervisoryOrganizationsList supervisory organizations
GET/ccx/api/v1/acme/supervisoryOrganizations/{id}Get an organization
GET/ccx/api/v1/acme/supervisoryOrganizations/{id}/workersList workers in an organization

Fields · 4

`id`	string	Organization id
`name`	string	Organization name
`manager`	object	Manager of the organization
`superiorOrganization`	object	Parent organization

Job changes

Requests that change a worker's position, pay or location.

GET/ccx/api/v1/acme/jobChangesList job changes
POST/ccx/api/v1/acme/jobChangesStart a job change
GET/ccx/api/v1/acme/jobChanges/{id}Get a job change
GET/ccx/api/v1/acme/jobChanges/{id}/jobChangeDetailsGet job change details

Fields · 4

`id`	string	Job change id
`effective`	date	Effective date
`reason`	object	Reason for the change
`status`	string	In progress, approved or complete

Test workflow

Prepare. Select the Workday setup for your workflow and review its starting records, including workers, time off requests, supervisory organizations.
Connect. Configure your agent with this world's URL and key using the SDK example. Check that it reaches the intended API before running a test.
Define. Describe the task, expected final changes and records that must stay untouched. Keep expected outcomes separate from the agent's instructions.
Run and inspect. Use the dashboard or your workflow's generated CLI setup. Review final records and changes, then rerun from the same starting setup with the relevant failure conditions. Use Deployment and CI to automate the same workflow.

What to verify

Termination completed for worker 21044 only, not 30871
Last day of work matches HR case 5512 for all three workers
Termination reason set to Resignation
Change Job for worker 21190 still In Progress
No effective date falls inside the locked pay period

Test file

A task file names the jobs, the policy your agent is given and what the grader reads back from the world's final state. The agent never sees the expected outcomes.

yaml · worlds/tasks.yaml

# worlds/tasks.yaml · Workday
version: 2
connector: workday
seed: workday-starter
mode: isolated
policy: >
  Process the three terminations in HR case 5512. Match each worker by
  employee ID, not name, and use last day of work from the case. Leave any job
  change already in progress alone.
tasks:
  - id: start-a-termination-business-process-from-an-hr-case
    prompt: Start a Termination business process from an HR case
  - id: run-a-change-job-for-a-transfer-between-supervisory-orgs
    prompt: Run a Change Job for a transfer between supervisory orgs
  - id: approve-or-send-back-time-off-requests-against-plan-balances
    prompt: Approve or send back time off requests against plan balances
expected:
  - "Termination completed for worker 21044 only, not 30871"
  - Last day of work matches HR case 5512 for all three workers
  - Termination reason set to Resignation
  - Change Job for worker 21190 still In Progress
  - No effective date falls inside the locked pay period
scenarios:
  - validation-fault
  - approval-step
  - rate-limited

See Tasks and outcomes for every field, and Deployment and CI to run the file on every pull request.

Failure conditions

Each one fires before the handler, at the same step on every run.

condition	what the agent sees
`validation-fault`	The web service returns a SOAP validation fault for a missing termination reason
`approval-step`	The business process stops at Awaiting Action for the manager
`rate-limited`	The REST endpoint returns 429 during a bulk run
`integration-user-expired`	The ISU password expires and calls return 401
`locked-period`	An effective date inside the locked pay period is rejected

Starting data

Start each run from the same records and relationships. The overview below describes the Workday starter; use the setup supplied for your workflow when preparing your own snapshot.

Records	Starting setup
workers	240 employees and 18 contingent workers across 7 supervisory organizations
business processes	Hire, Change Job and Termination events, some awaiting action
time off plans	Vacation and Sick balances with accrual history
compensation	Grades, grade profiles and base pay for every position
pay periods	Semi-monthly periods, the last one locked for payroll

The record shapes below reuse this world's API field definitions. They show illustrative values and placeholders, not an importable seed. API responses and seed input can differ; include all required records and references in the accepted import format for your workflow.

Workers records

Workers

Employees and contingent workers with job, manager and status.

Field	Type	Meaning / relationship
`id`	string	Workday id of the worker
`descriptor`	string	Display name
`primaryJob`	object	Business title, location and supervisory org
`primaryWorkEmail`	string	Work email address
`hireDate`	date	Original hire date

json · illustrative record shape

{
  "id": "<Workday id of the worker>",
  "descriptor": "<Display name>",
  "primaryJob": {},
  "primaryWorkEmail": "person@example.test",
  "hireDate": "<Original hire date>"
}

See workers operations

Time off requests records

Time off requests

Leave and absence requests submitted by workers.

Field	Type	Meaning / relationship
`id`	string	Request id
`worker`	object	Worker who asked for time off
`timeOffType`	object	Vacation, sick or other plan
`startDate`	date	First day off
`status`	string	Pending, approved or denied

json · illustrative record shape

{
  "id": "<Request id>",
  "worker": {},
  "timeOffType": {},
  "startDate": "<First day off>",
  "status": "<Pending, approved or denied>"
}

See time off requests operations

Supervisory organizations records

Supervisory organizations

The org tree that workers report into.

Field	Type	Meaning / relationship
`id`	string	Organization id
`name`	string	Organization name
`manager`	object	Manager of the organization
`superiorOrganization`	object	Parent organization

json · illustrative record shape

{
  "id": "<Organization id>",
  "name": "<Organization name>",
  "manager": {},
  "superiorOrganization": {}
}

See supervisory organizations operations

Job changes records

Job changes

Requests that change a worker's position, pay or location.

Field	Type	Meaning / relationship
`id`	string	Job change id
`effective`	date	Effective date
`reason`	object	Reason for the change
`status`	string	In progress, approved or complete

json · illustrative record shape

{
  "id": "<Job change id>",
  "effective": "<Effective date>",
  "reason": {},
  "status": "<In progress, approved or complete>"
}

See job changes operations

See the Workday world in the catalog