Workday REST API Testing with Postman

A practical walkthrough for integration developers: setting up OAuth 2.0, making your first calls, writing tests that catch real problems, and building a collection you can actually reuse.

Why Postman and Workday REST?

Workday’s API surface has two distinct layers. The older, larger layer is SOAP-based: hundreds of operations accessible via WSDL, requiring WS-Security headers and XML envelope construction. The newer layer is REST-based, introduced progressively from Workday 28 onwards, and it covers a growing set of operations in HCM, Absence, Payroll, and Financials using standard JSON over HTTPS.

REST API coverage in Workday is not yet at parity with SOAP, but for many of the most commonly needed operations (reading worker profiles, submitting absence requests, querying job profiles, pulling organisation data) REST is now the cleaner path. It is faster to build against, easier to debug, and far more compatible with modern tooling.

Postman is the right tool for working with Workday’s REST APIs during development and testing for three specific reasons. First, it handles OAuth 2.0 token management natively, which removes the most tedious part of Workday REST setup. Second, it lets you write JavaScript test assertions that run after each response, so you are not just checking that the call returned 200; you are verifying that the data is actually what you expected. Third, Postman Collections export to JSON that can be committed to source control and run headlessly via Newman in a CI/CD pipeline, which means your manual tests and your automated regression tests are the same thing.

Scope of This Article This article covers Workday’s REST API specifically, not the SOAP/WWS layer. If you need to test SOAP operations (Get_Workers, Hire, etc.), those require a different approach in Postman involving raw XML bodies and custom WS-Security headers. The patterns here apply to the REST endpoints documented in Workday’s API Explorer at {tenant}.workday.com/api/v1.

What Workday’s REST API Actually Looks Like

Before opening Postman, it helps to understand how Workday’s REST API is structured, because it differs from a typical REST API in a few important ways.

Base URL Pattern

Workday REST endpoints follow this pattern:

https://{hostname}/api/{version}/{tenant}/{resource}# Examples: https://wd2-impl-services1.workday.com/api/v1/acmecorp/workers https://wd2-impl-services1.workday.com/api/v1/acmecorp/workers/{workerId}/absenceInputs https://wd2-impl-services1.workday.com/api/v1/acmecorp/organizations# The version segment (v1) is fixed for now; Workday has not yet released v2 # The tenant name is your Workday tenant identifier, visible in your tenant URL

How Workday Identifies Workers in REST

This is the part that confuses most developers on first contact. Workday’s REST API does not use the Employee_ID you are used to from the SOAP layer as the primary resource identifier. REST endpoints use an internal Workday ID: a long alphanumeric string that is stable but not human-readable.

To get a worker’s REST ID, you first query the workers collection and filter by Employee ID:

GET /api/v1/{tenant}/workers?search={employeeId}# Response includes: { “data”: [ { “id”: “3aa5550b7fe348b5ae88c3af1b48c573”, // this is the REST resource ID “descriptor”: “Jane Smith”, “href”: “/api/v1/acmecorp/workers/3aa5550b7fe348b5ae88c3af1b48c573” } ], “total”: 1 }

You then use this internal ID for all subsequent calls against that worker resource. Store it as a Postman variable at request time; the test section of the workers search call is the right place to capture it automatically.

Pagination

Workday REST uses offset-based pagination with two query parameters: limit (default 20, max 100) and offset (zero-indexed). Every collection response includes a total field telling you how many records exist in total.

# Page 1: first 100 records GET /api/v1/{tenant}/workers?limit=100&offset=0# Page 2: next 100 records GET /api/v1/{tenant}/workers?limit=100&offset=100# Response always includes: { “data”: [ … ], “total”: 4837, // total records matching your filter “offset”: 0, “limit”: 100 }

Workday REST API Explorer

Workday provides an interactive API Explorer for your tenant at:

https://{your-tenant}.workday.com/api/v1/{tenant}# Also accessible from your tenant: # Home > Menu > API Explorer (may require the ISU to have correct domain access)

The Explorer shows every available endpoint for your tenant, the required and optional parameters for each, and example responses. Use it to discover what is available before building requests in Postman; it is faster than reading documentation and shows what your specific tenant version supports.

Setting Up OAuth 2.0 in Postman

Workday’s REST API requires OAuth 2.0. There is no username/password option for REST the way there is for SOAP. The correct grant type for server-to-server integration testing is Client Credentials: your application authenticates as itself, not on behalf of a specific user.

Step 1: Create an API Client in Workday

Before Postman can authenticate, you need to register an API client in your Workday tenant. This is done by an administrator with access to the Register API Client for Integrations task.

• In Workday, search for the task: Register API Client for Integrations
• Set the Client Name to something descriptive, for example: Postman_Dev_Testing
• Select the Non-Expiring Refresh Tokens option if you want tokens that persist beyond the standard 12-hour window (useful for development)
• Under Scope (Functional Areas), add the areas you need to test: for example, Staffing, Absence Management, Compensation
• Save the client. Workday will display the Client ID and Client Secret exactly once. Copy them immediately.

Client Secret Visibility Workday shows the Client Secret only at the time of creation. If you close the screen without copying it, you must generate a new secret; there is no way to retrieve the original. Store it in a password manager or your team’s secrets store immediately.

Step 2: Get the Token Endpoint URL

The OAuth 2.0 token endpoint is tenant-specific:

https://{your-tenant}.workday.com/ccx/oauth2/{tenant-name}/token# Example: https://wd2-impl-services1.workday.com/ccx/oauth2/acmecorp/token# You can also find it via the .well-known endpoint: https://{your-tenant}.workday.com/ccx/oauth2/{tenant-name}/.well-known/openid-configuration

Step 3: Configure the OAuth 2.0 Token in Postman

In Postman, the cleanest approach is to configure OAuth 2.0 at the Collection level so every request in the collection inherits it automatically. Open your collection, go to the Authorization tab, and set:

Postman Field	Value
Type	OAuth 2.0
Grant Type	Client Credentials
Access Token URL	https://{tenant-host}/ccx/oauth2/{tenant-name}/token
Client ID	Your client ID from the API client registration
Client Secret	Your client secret (store as a Postman variable, not inline)
Scope	Leave blank; Workday ignores scope in the token request and uses the API client’s registered functional areas
Client Authentication	Send as Basic Auth header

Click Get New Access Token, then Use Token. Postman will add the Bearer token to the Authorization header of every request in the collection. The token expires after the configured duration (typically 1 hour for non-expiring-refresh-token clients, or as configured). Postman will show an expiry indicator; when it expires, click the refresh button to get a new one.

Step 4: Store Credentials as Postman Variables

Never type your Client ID, Client Secret, or tenant name directly into request fields. Store them as Collection variables and reference them everywhere:

# Postman Collection Variables: set these in the Collection > Variables tabVariable Name Initial Value (example) Current Value ──────────────────────────────────────────────────────────────────────────── workday_tenant_host wd2-impl-services1.workday.com wd2-impl-services1.workday.com workday_tenant_name acmecorp acmecorp workday_client_id abc123xyz… [set but hidden] workday_client_secret secretvalue… [set but hidden] workday_api_base {{workday_tenant_host}}/api/v1/{{workday_tenant_name}} workday_worker_id (empty; populated by test scripts at runtime)# In your requests, reference them like: GET https://{{workday_api_base}}/workers

Setting Initial Value to empty or a placeholder for secrets and only populating Current Value means the secrets are not exported when you share the collection with teammates; only the variable names are exported, not the values.

Building Your First Workday REST Requests

Request 1: Get Workers (Collection Query)

This is the starting point for almost every Workday REST workflow. It returns a paginated list of workers with their internal REST IDs.

Method: GET URL: https://{{workday_api_base}}/workersQuery Parameters: limit = 20 offset = 0 search = (optional; employee name or ID substring)Headers: Authorization: Bearer {{access_token}} (set automatically if collection auth is configured) Content-Type: application/json # No request body needed for GET calls

Expected response:

HTTP 200 OK{ “data”: [ { “id”: “3aa5550b7fe348b5ae88c3af1b48c573”, “descriptor”: “Jane Smith”, “href”: “https://wd2-impl-services1.workday.com/api/v1/acmecorp/workers/3aa5550b7fe348b5ae88c3af1b48c573” }, { “id”: “8bc9921e4ad04c6d93b1a7f2e890d447”, “descriptor”: “John Davis”, “href”: “https://wd2-impl-services1.workday.com/api/v1/acmecorp/workers/8bc9921e4ad04c6d93b1a7f2e890d447” } ], “total”: 4837, “offset”: 0, “limit”: 20 }

In the Tests tab of this request, add a script to capture the first worker’s ID as a variable for use in subsequent requests:

// Postman Test Script: capture first worker ID for downstream callspm.test(“Status is 200”, function () { pm.response.to.have.status(200); });pm.test(“Response has data array”, function () { const body = pm.response.json(); pm.expect(body.data).to.be.an(‘array’); pm.expect(body.data.length).to.be.greaterThan(0); }); pm.test(“Each worker has id and descriptor”, function () { const body = pm.response.json(); body.data.forEach(function(worker) { pm.expect(worker.id).to.be.a(‘string’).and.not.empty; pm.expect(worker.descriptor).to.be.a(‘string’).and.not.empty; }); }); // Capture first worker ID for chained requests const body = pm.response.json(); if (body.data && body.data.length > 0) { pm.collectionVariables.set(“workday_worker_id”, body.data[0].id); pm.collectionVariables.set(“workday_worker_name”, body.data[0].descriptor); console.log(“Captured worker ID:”, body.data[0].id); }

Request 2: Get Single Worker Detail

Once you have a worker’s REST ID, you can retrieve their full record:

Method: GET URL: https://{{workday_api_base}}/workers/{{workday_worker_id}}# No query parameters needed for a single resource fetch # No body needed

The response structure is significantly richer than the collection summary; it includes subresource references for personal data, employment data, compensation, and more:

HTTP 200 OK{ “id”: “3aa5550b7fe348b5ae88c3af1b48c573”, “descriptor”: “Jane Smith”, “businessTitle”: “Senior Software Engineer”, “primaryJob”: { “id”: “a1b2c3d4e5f6789012345678abcdef01”, “descriptor”: “Senior Software Engineer”, “href”: “…/jobs/a1b2c3d4e5f6789012345678abcdef01” }, “primarySupervisoryOrganization”: { “id”: “f0e1d2c3b4a5968778695a4b3c2d1e0f”, “descriptor”: “Engineering – Platform”, “href”: “…/organizations/f0e1d2c3b4a5968778695a4b3c2d1e0f” }, “workerType”: { “id”: “d290f1ee-6c54-4b01-90e6-d701748f0851”, “descriptor”: “Employee” } }

Request 3: Get Worker’s Absence Inputs

Subresources in Workday REST are accessed via a nested URL path under the worker:

Method: GET URL: https://{{workday_api_base}}/workers/{{workday_worker_id}}/absenceInputsQuery Parameters: limit = 10 offset = 0# Returns the worker’s recent absence/time-off entries

Request 4: Submit an Absence Request (POST)

POST requests to Workday REST require a JSON body. The structure is specific to each resource; check the API Explorer for the exact schema. Here is an absence input submission:

Method: POST URL: https://{{workday_api_base}}/workers/{{workday_worker_id}}/absenceInputsHeaders: Authorization: Bearer {{access_token}} Content-Type: application/jsonBody (raw JSON): { “date”: “2025-03-10”, “type”: { “id”: “{{absence_type_id}}” }, “dailyQuantity”: 8, “comment”: “Planned leave; annual vacation”, “status”: { “id”: “{{absence_status_id}}” } }

One important difference from the SOAP layer: Workday REST POST calls are not transactional in the same way. A 201 Created response means the record was accepted by the API layer, but Workday’s business process rules may still reject it asynchronously if there is a policy violation (for example, insufficient leave balance). You need to poll the resource or check the business process monitor to confirm the final state.

Writing Tests That Actually Catch Problems

Postman’s Tests tab runs JavaScript after every response. Most developers stop at pm.response.to.have.status(200), which tells you almost nothing about whether Workday returned what you actually needed. The following test patterns catch the problems that matter in Workday integrations.

Test Pattern 1: Response Time SLA

Workday REST calls that are slow (over 10 seconds) usually indicate a misconfigured filter, a report-backed endpoint under load, or a network routing issue. Flag them explicitly:

// Warn if response exceeds expected time threshold pm.test(“Response time under 5000ms”, function () { pm.expect(pm.response.responseTime).to.be.below(5000); });// For endpoints known to be slower (org hierarchy, large collections) pm.test(“Response time under 15000ms for large collection”, function () { pm.expect(pm.response.responseTime).to.be.below(15000); });

Test Pattern 2: Required Fields Present

Workday can return a 200 with an empty or partial record if the ISU does not have access to a particular domain. Test that the fields your integration actually depends on are present and non-null:

pm.test(“Worker has required integration fields”, function () { const worker = pm.response.json();// Fields your integration maps downstream: test each one explicitly pm.expect(worker.id, “id missing”) .to.be.a(‘string’).and.not.empty; pm.expect(worker.descriptor, “descriptor missing”) .to.be.a(‘string’).and.not.empty; pm.expect(worker.businessTitle, “businessTitle missing”) .to.be.a(‘string’).and.not.empty; pm.expect(worker.primaryJob, “primaryJob missing”) .to.exist; pm.expect(worker.primaryJob.id, “primaryJob.id missing”) .to.be.a(‘string’).and.not.empty; pm.expect(worker.primarySupervisoryOrganization, “primarySupervisoryOrganization missing”) .to.exist; });

Test Pattern 3: Data Type and Format Validation

Workday REST returns dates as strings in ISO 8601 format. IDs are lowercase hex strings. If these formats ever change (which can happen across Workday releases) your integration will silently receive differently-formatted data. Test the format, not just presence:

pm.test(“Date fields are ISO 8601 format”, function () { const body = pm.response.json();// Test every date field your integration reads if (body.hireDate) { pm.expect(body.hireDate).to.match( /^\d{4}-\d{2}-\d{2}$/, “hireDate must be YYYY-MM-DD” ); } if (body.terminationDate) { pm.expect(body.terminationDate).to.match( /^\d{4}-\d{2}-\d{2}$/, “terminationDate must be YYYY-MM-DD” ); } });pm.test(“Resource IDs are non-empty strings”, function () { const body = pm.response.json(); // Workday REST IDs are 32-char hex strings (UUID-like, no hyphens) if (body.id) { pm.expect(body.id).to.match( /^[a-f0-9]{32}$/, “id should be 32-char hex string” ); } });

Test Pattern 4: Pagination Integrity

When testing collection endpoints, verify that pagination metadata is consistent with actual data returned:

pm.test(“Pagination metadata is consistent”, function () { const body = pm.response.json();pm.expect(body.total).to.be.a(‘number’).and.at.least(0); pm.expect(body.limit).to.be.a(‘number’).and.greaterThan(0); pm.expect(body.offset).to.be.a(‘number’).and.at.least(0); pm.expect(body.data).to.be.an(‘array’);// data.length should never exceed the limit pm.expect(body.data.length).to.be.at.most(body.limit, “data array length should not exceed limit”); // on the last page, data.length can be less than limit; that’s fine // but data.length should never be 0 unless total is 0 if (body.total > 0) { pm.expect(body.data.length).to.be.greaterThan(0, “data should not be empty when total > 0”); } });

Test Pattern 5: Error Response Shape

Test that your error handling cases are covered, not just the happy path. Add a duplicate request configured to trigger a 400 or 403, and verify the error response shape is what your code expects:

// Run this against a request you know will return 400 (e.g., invalid date format) pm.test(“400 error response has expected structure”, function () { pm.response.to.have.status(400);const body = pm.response.json();// Workday REST error responses have this consistent structure: pm.expect(body.error).to.be.a(‘string’).and.not.empty; // Some endpoints also return an errors array: if (body.errors) { pm.expect(body.errors).to.be.an(‘array’); body.errors.forEach(function(err) { pm.expect(err.error).to.be.a(‘string’); }); } }); // Run this against a request using an ISU without access to the domain pm.test(“403 error is explicit, not a silent empty response”, function () { // Workday sometimes returns 200 with empty data instead of 403 // when the ISU lacks domain access; this test catches that pattern const body = pm.response.json(); if (pm.response.status === 200 && body.total === 0) { console.warn(“WARNING: Empty response; may indicate missing ISU domain access, not genuinely no data”); } });

The Silent 200 Problem Workday REST has a well-known behaviour where an ISU without access to a domain security policy returns HTTP 200 with an empty data array rather than HTTP 403 Forbidden. This means your test will pass (status is 200) even though your ISU cannot read the data. Always test with a known worker who has data and verify that data is actually returned, not just that the status code is 200.

Structuring a Reusable Workday Postman Collection

A Postman collection you build once and use repeatedly (for development, for regression testing before releases, for onboarding new integration developers) needs to be structured deliberately. The following folder structure works well for Workday:

Workday REST API: {Tenant Name} │ ├── 📁 Auth │ └── GET Token (manual token retrieval test; verify OAuth is working) │ ├── 📁 Workers │ ├── GET Workers (collection, paginated) │ ├── GET Worker by ID │ ├── GET Workers: search by Employee ID │ └── GET Workers: filter by org │ ├── 📁 Worker Subresources │ ├── GET Worker Absence Inputs │ ├── GET Worker Jobs │ ├── GET Worker Organizations │ └── POST Absence Input (submit absence) │ ├── 📁 Organizations │ ├── GET Organizations (all) │ ├── GET Organization by ID │ └── GET Organization Workers (org members) │ ├── 📁 Reference Data │ ├── GET Absence Types │ ├── GET Job Profiles │ └── GET Organization Types │ ├── 📁 Error Cases │ ├── GET Worker: invalid ID (expect 404) │ ├── POST Absence: missing required field (expect 400) │ └── GET Workers: no ISU access (expect 200 empty or 403) │ └── 📁 Integration Smoke Tests ├── Full Worker Lifecycle Read (chained: search > get > subresources) └── Pre-Release Regression (run before every Workday release)

Collection-Level Pre-Request Script

Add a Pre-request Script at the collection level to automatically check whether the access token is still valid and refresh it if needed. This prevents failed runs caused by an expired token without requiring manual intervention:

// Collection-level Pre-request Script // Checks token expiry and refreshes automaticallyconst tokenExpiry = pm.collectionVariables.get(“token_expiry”); const now = Date.now();// If token expires in less than 5 minutes, refresh it if (!tokenExpiry || parseInt(tokenExpiry) < now + (5 * 60 * 1000)) { const tokenUrl = “https://” + pm.collectionVariables.get(“workday_tenant_host”) + “/ccx/oauth2/” + pm.collectionVariables.get(“workday_tenant_name”) + “/token”; const clientId = pm.collectionVariables.get(“workday_client_id”); const clientSecret = pm.collectionVariables.get(“workday_client_secret”); const credentials = btoa(clientId + “:” + clientSecret); pm.sendRequest({ url: tokenUrl, method: “POST”, header: { “Content-Type”: “application/x-www-form-urlencoded”, “Authorization”: “Basic “ + credentials }, body: { mode: “urlencoded”, urlencoded: [ { key: “grant_type”, value: “client_credentials” } ] } }, function (err, res) { if (err) { console.error(“Token refresh failed:”, err); return; } const body = res.json(); if (body.access_token) { pm.collectionVariables.set(“access_token”, body.access_token); // expires_in is in seconds; store absolute expiry timestamp const expiry = Date.now() + (body.expires_in * 1000); pm.collectionVariables.set(“token_expiry”, expiry.toString()); console.log(“Token refreshed. Expires in”, body.expires_in, “seconds.”); } else { console.error(“Token response missing access_token:”, JSON.stringify(body)); } }); }

Running Collections Headlessly with Newman

Once your Postman collection is built and tested interactively, you can run it in a CI/CD pipeline using Newman (Postman’s command-line runner). This turns your manual test collection into an automated regression suite that can run before every deployment, before every Workday biannual release, or on a nightly schedule.

Install and Run Newman

# Install Newman globally npm install -g newman# Export your collection from Postman: # Collection > … > Export > Collection v2.1 > Save as workday_collection.json# Export your environment (variables) from Postman: # Environments > … > Export > Save as workday_env.json # Run the collection newman run workday_collection.json \ –environment workday_env.json \ –reporters cli,json \ –reporter-json-export results/newman_run_$(date +%Y%m%d_%H%M%S).json \ –bail # stop on first test failure (remove for full run) # Run only a specific folder within the collection newman run workday_collection.json \ –environment workday_env.json \ –folder “Integration Smoke Tests”

Handling Secrets in Newman CI Runs

You should not commit your Postman environment file with real credentials to source control. The standard approach is to override specific variables at run time via the --env-var flag:

# Override sensitive variables at runtime (from CI/CD secrets store) newman run workday_collection.json \ –environment workday_env.json \ –env-var “workday_client_id=$ENV_WORKDAY_CLIENT_ID” \ –env-var “workday_client_secret=$ENV_WORKDAY_CLIENT_SECRET” \ –env-var “workday_tenant_name=$ENV_WORKDAY_TENANT” \ –reporters cli,json \ –reporter-json-export results/output.json# The environment file contains the variable names with empty values. # CI secrets populate the actual values at runtime. # This pattern works with GitHub Actions, GitLab CI, Jenkins, and Azure Pipelines.

GitHub Actions Example

# .github/workflows/workday-api-tests.yml name: Workday REST API Regression Testson: schedule: – cron: ‘0 6 * * 1-5’ # Run weekdays at 06:00 UTC (before business hours) workflow_dispatch: # Also allow manual triggerjobs: api-tests: runs-on: ubuntu-latest steps: – uses: actions/checkout@v4 – name: Setup Node.js uses: actions/setup-node@v4 with: node-version: ’20’ – name: Install Newman run: npm install -g newman – name: Run Workday API Tests run: | newman run postman/workday_collection.json \ –environment postman/workday_env_sandbox.json \ –env-var “workday_client_id=${{ secrets.WORKDAY_CLIENT_ID }}” \ –env-var “workday_client_secret=${{ secrets.WORKDAY_CLIENT_SECRET }}” \ –reporters cli,json \ –reporter-json-export results/output.json – name: Upload Test Results uses: actions/upload-artifact@v4 if: always() # Upload even if tests failed with: name: newman-results path: results/

Common Errors and What They Actually Mean

Error / Status	Actual Cause and Fix
401 Unauthorized	Token is missing, expired, or the Authorization header is malformed. Verify the Bearer prefix is present and the token has not expired. Also check that the API client is active and not disabled in Workday.
403 Forbidden	The API client’s registered scope does not include the functional area you are calling. Return to Register API Client for Integrations and add the required functional area to the client’s scope.
200 OK with empty data []	Almost always means the ISU or API client lacks domain security access to the data you requested, not that the data does not exist. Check domain security policies in Workday for the relevant functional area.
404 Not Found on a worker	The worker REST ID is invalid or does not exist in this tenant. Remember that REST IDs differ between sandbox and production; a valid ID from sandbox will 404 in production.
400 Bad Request on POST	Request body does not match the expected schema. The response body will include an error message specifying which field failed validation. Common causes: wrong ID type for a reference field, date in wrong format (must be YYYY-MM-DD), or a required field missing.
429 Too Many Requests	You have hit Workday’s API rate limit. Back off and retry with exponential delay. For test suites, add a delay between requests using pm.execution.delay(500) in your pre-request script.
500 Internal Server Error	Usually a Workday-side issue, occasionally triggered by a request body that passes schema validation but contains a value Workday cannot process. Check the Workday Integration Activity report in your tenant for details.
SSL certificate error in Postman	Your corporate proxy is performing TLS inspection. Go to Postman Settings > General and turn off SSL certificate verification for development. Do not disable this in production Newman runs.

Testing Across Sandbox and Production

Workday organisations typically have at least two tenants: a sandbox (or implementation tenant) and production. Your Postman collection needs to work across both without duplication.

The right approach is to use Postman Environments (one per tenant) and keep the collection itself environment-agnostic:

# Environment: Workday Sandbox workday_tenant_host = wd2-impl-services1.workday.com workday_tenant_name = acmecorp_sandbox workday_client_id = [sandbox client ID] workday_client_secret = [sandbox client secret]# Environment: Workday Production workday_tenant_host = wd2-services1.workday.com workday_tenant_name = acmecorp workday_client_id = [production client ID] workday_client_secret = [production client secret]# The collection uses {{workday_tenant_host}} and {{workday_tenant_name}} everywhere. # Switching environments in Postman switches the target tenant with no other changes.

One important practical note: do not run POST requests against production during testing. Workday REST POST calls create real business process transactions. A test absence submission in production creates an actual absence record for a real employee. Your test folder structure should separate read-only requests (safe to run anywhere) from write requests (sandbox only), and Newman runs in CI should target sandbox unless you are specifically validating a production deployment.

Quick Reference: Workday REST Endpoint Cheatsheet

What You Need	Endpoint
List all workers (paginated)	GET /api/v1/{tenant}/workers?limit=100&offset=0
Search worker by name or ID	GET /api/v1/{tenant}/workers?search={term}
Get single worker detail	GET /api/v1/{tenant}/workers/{workerId}
Get worker’s jobs	GET /api/v1/{tenant}/workers/{workerId}/jobs
Get worker’s organizations	GET /api/v1/{tenant}/workers/{workerId}/organizations
Get worker’s absence inputs	GET /api/v1/{tenant}/workers/{workerId}/absenceInputs
Submit absence request	POST /api/v1/{tenant}/workers/{workerId}/absenceInputs
List all organizations	GET /api/v1/{tenant}/organizations
Get org members	GET /api/v1/{tenant}/organizations/{orgId}/workers
List absence types (reference)	GET /api/v1/{tenant}/values/absenceInputs/type
List job profiles (reference)	GET /api/v1/{tenant}/jobProfiles
Get business site locations	GET /api/v1/{tenant}/locations

 

Building integrations against Workday’s REST API? If you are past the Postman exploration stage and building production integrations against Workday REST, our Workday Integration Services team builds and maintains production REST and SOAP integrations across HCM, Payroll, Recruiting, and Financials. If you have a Workday REST integration that is behaving unexpectedly (returning empty data, failing after a Workday release, or hitting rate limits under load), our Support & Troubleshooting service covers REST API diagnostics including ISU domain access review, response analysis, and test coverage gaps. For teams deciding whether to build REST-based integrations or use Workday Studio and EIB, our Custom Integration Development practice can help you evaluate the right approach for your specific use case and data volume.