The fix: add includeTerminatedWorkers=true

The staffing service's GET /workers leaves terminated workers out unless you ask for them with the includeTerminatedWorkers query parameter. Workday's reference describes it as a boolean that includes terminated workers in the output, so the request becomes:

GET https://{apiGatewayBasePath}/staffing/v7/workers?includeTerminatedWorkers=true&limit=100&offset=0

The parameter is on staffing v7 and on the /workers collections of other services that publish one, such as compensation v3 and timeTracking v7. It is not on the older common/v1 GET /workers, whose only query parameters are limit, offset and search. If your integration calls common/v1/workers and needs former employees, switching to a staffing version is the fix; no parameter will make the common endpoint return them.

For integrations that call the tenant host instead of the API gateway, the path is https://{tenantHostname}/api/staffing/v7/{tenant}/workers, with the same query string.

Why GET /workers returns only current workers by default

Workday describes GET /workers as retrieving workers and their current staffing information, and describes its REST APIs in general as built for small self-service transactions that return a small set of information quickly. That is the job of a worker picker or a manager page, where former employees are noise, so they are left out unless the caller sets the flag. The terminated worker's record is still in the tenant.

The other parameters narrow the same collection:

  • search: by name or worker ID, case-insensitive. Space-separated terms are an OR search, so search=21001 21002 returns both.
  • email: workers whose email matches.
  • filterByOrgVisibility: only workers whose supervisory organizations the calling user can see. Workday notes it requires the Enable Restrictions on Worker Prompts Based on Supervisory Org Visibility Settings option in Edit Tenant Setup - System.
  • limit and offset for paging: 20 per page by default, 100 at most.

Workday's Contact Information Changes guide uses the same combination: call GET /workers with includeTerminatedWorkers or search to find the worker ID before acting on a person.

Still missing someone after adding the parameter

If a known former employee is still absent, check these in order.

The parameter did not go out as written. The name is includeTerminatedWorkers, exactly as Workday spells it, and the value is a boolean. Send the literal true and check the request your client actually sent, not the code that built it.

You stopped at the first page. With the parameter on, the collection is larger, and the default page is 20. Read total in the response and keep increasing offset by your limit until you have that many. Workday's fundamentals show the pattern: GET /workers?limit=5&offset=99 returns five workers starting with the 100th.

The account cannot see them. GET /workers in staffing v7 is secured by the FLW Service, Self-Service: Current Staffing Information and Worker Data: Public Worker Reports domains, and like every Workday read it returns only what the calling account's security allows. An integration system user or a user whose security groups do not cover terminated workers will get a shorter list even with the parameter set. Test by running the same request as an account you know has access to the worker, and compare.

You are searching the wrong way. If you have the employee ID, skip the collection and fetch the worker directly. The {ID} path parameter accepts a Workday ID, a reference ID of type Employee_ID or Contingent_Worker_ID, or me:

GET https://{apiGatewayBasePath}/staffing/v7/workers/Employee_ID=21001

Workday's reference does not say whether this single-worker GET filters out terminated workers, so test it in your tenant with a known former employee before you build on it.

Other ways to get former workers

If you need many former workers with specific fields, the staffing collection is a poor fit: 100 workers per page at most, and only the fields that endpoint returns.

WQL

WQL queries a data source and returns the fields you select. Data sources can take optional parameters, and the WQL REST API's GET /dataSources/{ID} lists them; Workday's example response for that call shows an optional Boolean parameter labelled Include Terminated Workers with the alias includeTerminatedWorkers. Check the data source you plan to use, because which worker data sources include terminated workers, and whether they take that parameter, varies by data source.

The FROM clause also takes effectiveAsOfDate and entryMoment for Workday-delivered data sources, which runs the query as of that date instead of now:

SELECT fullName
FROM allWorkers (effectiveAsOfDate="2026-01-01")

Row limits and paging for WQL are covered in getting more than 500 rows from WQL, and the syntax in the WQL guide.

SOAP Get_Workers

Get_Workers in the Human_Resources web service has a request flag in its WSDL, Exclude_Inactive_Workers, that excludes terminated employees and contingent workers whose contracts have ended. Leave it unset or false and they are included. Get_Workers also supports transaction-log criteria for finding workers who had a termination in a date range, which is often the real requirement behind "include terminated workers". Workday's Get Workers guide covers the Updated and Effective date windows and recommends requesting only the data sections you need. For change detection on terminations, see Core Connector: Worker change detection.

Prove the fix

Pick two workers you can check in the Workday UI: one active and one terminated within the period you care about. Run your request with includeTerminatedWorkers=true, page through to total, and confirm both IDs are in the result. Then run it without the parameter and confirm only the active one is. If the terminated worker is missing in both runs, the cause is security or paging, not the parameter.

Sources checked