The ID is in the response body, not a header

When a Workday REST POST creates something, the 201 response body is the new object, and its id field is the new instance's Workday ID, a 32-character identifier. Read $.id from the body. Workday's REST reference does not document a Location header on create responses, so code that waits for one gets nothing.

Workday's REST fundamentals say every object in a response carries id, descriptor and href. A create response is no exception. Here is the first entry from Workday's own sample of creating a prospect:

{
  "id": "89c65f66c91190000b9b9b883ec70000",
  "descriptor": "Jane Prospect",
  "candidate": {
    "id": "89c65f66c91190000b9b9c21c2ef0000",
    "descriptor": "Jane Prospect"
  }
}

Two IDs are in there. The top-level id is the prospect; candidate.id is a related object created with it. Take the top-level one unless the next call is about the child. Use the value as returned in later paths, for example GET /recruiting/v3/prospects/89c65f66c91190000b9b9b883ec70000.

When the ID you get is an event, not the record

Many Workday REST writes are business processes, and for those the POST returns the event, not the finished change. The REST API Explorer's description of POST /workers/{ID}/jobChanges is explicit: it starts a new job change event and returns a new job change ID, and nothing persists until you call POST /jobChanges/{ID}/submit.

So the ID from the first POST is a handle for the steps that follow:

  1. POST /workers/Employee_ID=21001/jobChanges returns {"id": "<event id>", ...} with status 201.
  2. PATCH /jobChanges/<event id>/location/<event id> and the other subresource calls use it.
  3. POST /jobChanges/<event id>/submit with an empty body {} returns the event state: id, descriptor, status and businessProcessParameters, including the overall business process and its status.

No separate ID comes back for the changed job data itself; the event ID is the only handle. After submit, the status may be In Progress while the process waits for approval, so read the worker's job data back only once the process has completed. If you only need the outcome, the submit response's businessProcessParameters tells you whether it is still in progress.

No ID in validate-only mode

If the request carries x-validate-only: 1, Workday runs the validations, persists nothing, and returns 200 instead of 201. There is no instance, so there is no usable ID. That header is easy to leave on after testing in Postman. If your POST returns 200 and the ID you read finds nothing, check for it first; Workday says to resend with the header removed or set to 0 to commit.

Getting the ID in each tool

The mechanics are the same everywhere; only the syntax for reading $.id changes.

Postman or curl

Read id from the JSON body. In Postman, a test script can store it for the next request: pm.collectionVariables.set("eventId", pm.response.json().id);. Then use {{eventId}} in the next URL.

Orchestrate

In an orchestration, the Send Workday API Request step's response is available to later steps. Read the ID with a JSONPath accessor:

data("StartChangeJob", "response").asJSON().stringAtJsonPath("$.id")

Workday's App Catalog samples read response IDs with this same accessor. Put it in a Create Values step, then build the next path from it with string interpolation. Written the way Workday's App Catalog sample orchestrations write their paths, that is s"${"/staffing/v6/jobChanges/"}${data("SetValues", "eventId")}${"/submit"}".

Batch Protocol

Inside a batch you do not read the ID yourself. A later subrequest refers to an earlier one by name:

"relativeUri": "staffing/v6/jobChanges/{startChangeJobEvent:$.id}/submit"

The batch runs as one transaction, so if any step fails the initiated event is rolled back rather than left behind. The rules for these references are in the Workday REST batch protocol guide.

Extend pages

On an Extend edit page, outbound endpoints run in the order they are listed when the user submits. Workday's App Catalog samples use the response of an earlier outbound endpoint in a later one by its name: the Document Intelligence sample posts a file to its documents collection in an endpoint named document, then passes <% document.id %> to the orchestration it launches next.

Bulk creates of Extend business objects

A POST with bulk=true to an Extend business object collection returns data[], one entry per record, each with its own status and body. Workday documents that the responses come back in the same order as the records you sent, so match by position: the third response belongs to the third record. Entries that failed have status 400 and an errors body instead of an id, so check status before reading body.id.

Reference IDs instead of WIDs

The id you get back is a Workday ID. Many endpoints also accept a reference ID in the path, in the form Reference_ID_Type=value, such as Employee_ID=21005; the valid types for each endpoint are listed in its {ID} parameter description. If your integration keys records by an external number, store the returned WID alongside it. A reference ID only works where the endpoint lists that type, and the WID works everywhere.

Prove you have the right ID

GET the object with the ID you captured and compare the descriptor to what you created. For a business process, GET the event or read the submit response and check the overall status. If the GET returns 404 or 403, check three causes: that you read a child object's id instead of the top-level one, that the request ran in validate-only mode, or that the account making the GET lacks the domain that secures that endpoint, which the REST API Explorer lists per operation.

If you are deciding between REST and the Graph API for reads after the write, see Workday Extend Graph API vs REST API.

Sources checked