Get_Event_Documents lists integration output files but does not return their content

An integration event is Workday's record of one integration run: its status, messages, launch parameters, timestamps and its attached documents, which the UI calls output files. Through the Integrations web service you can find events with Get_Integration_Events and list each event's documents with Get_Event_Documents. Both return document metadata and references: file name, document ID, size, content type, expiry and tags. Neither operation's response schema has an element for the file content itself.

To read the content programmatically inside Workday, use Orchestrate. A Workday Integration System orchestration can trigger the integration and receive its documents as step outputs, or find and retrieve stored documents by collection and entry ID. The rest of this guide covers both, and where each stops.

Find the event: Get_Integration_Events

Get_Integration_Events (Integrations web service; the examples here use v45.1) takes either specific event references or search criteria:

  • Request_References > Integration_Event_Reference, with an ID of type WID or Background_Process_Instance_ID.
  • Request_Criteria, with Integration_System_Reference, Integration_Event_Status_Reference (for example Completed or Failed), and a Sent_After and Sent_Before window.
<bsvc:Get_Integration_Events_Request bsvc:version="v45.1" xmlns:bsvc="urn:com.workday/bsvc">
  <bsvc:Request_Criteria>
    <bsvc:Integration_System_Reference>
      <bsvc:ID bsvc:type="Integration_System_ID">INT_Payroll_Outbound</bsvc:ID>
    </bsvc:Integration_System_Reference>
    <bsvc:Sent_After>2026-11-03T00:00:00Z</bsvc:Sent_After>
    <bsvc:Sent_Before>2026-11-04T00:00:00Z</bsvc:Sent_Before>
  </bsvc:Request_Criteria>
  <bsvc:Response_Filter>
    <bsvc:Count>100</bsvc:Count>
  </bsvc:Response_Filter>
</bsvc:Get_Integration_Events_Request>

Each returned Integration_Event has two blocks. Integration_Event_Data carries the integration system, Initiated_DateTime, Completed_DateTime, the latest Integration_Response_Message, the account that initiated it and the runtime parameters. Background_Process_Instance_Data carries the run's status, its messages, and the documents: Output_Document_Data for output files, plus a Log_File_Reference and a Consolidated_Report_Reference from the integration server.

Page with Response_Filter: Count takes 1 to 999 and defaults to 100, and Response_Results returns Total_Results and Total_Pages.

List the documents: Get_Event_Documents

Get_Event_Documents takes one or more Integration_Event_Reference values and returns, for each event, its Repository_Document entries. Each has a Repository_Document_Reference (ID types WID, Document_ID, File_ID or Integration_Service_Component_ID) and Repository_Document_Data with:

  • File_Name and Document_ID attributes,
  • File_Size in bytes, Content_Type and Content_Type_Reference,
  • Document_Type_Reference, Document_Tag_Reference and Custom_Document_Tag,
  • Owner_Reference,
  • Expiration_Timestamp,
  • Secured_Instance_Reference, for documents on integrations that use document security.

The request references also take an Ignore_Invalid_References attribute, for batches of event IDs where some may no longer resolve.

This is enough to monitor output: confirm last night's run produced a file, check its size is not zero, alert before Expiration_Timestamp, or reconcile the file name against what the downstream system received. It is not enough to download the file.

Read the content: Orchestrate

Run the integration and take its documents

The Trigger Integration step launches a child integration (a Studio integration, a packaged integration or another orchestration integration system; EIBs are not supported) and pauses the orchestration. When the child integration's business process completes, Workday calls back and the step exposes the child's status, messages and documents as outputs, so the next steps can read, transform or send the file. This is the documented way to chain integrations so one's output becomes the next one's input.

Mind the run-as user. If the child integration system has an ISU in its definition, the ISU is the run-as user and the step's credential is only the initiating user, who still needs permission to launch it. If it has no ISU, the step's user is both, and needs permission to run and launch.

Find and retrieve stored documents

When documents were stored by an orchestration with Store Document, read them back with:

  • Find Documents: give a reference ID and it returns metadata for every document stored with that reference ID in the launch event's collection: title, contentType, size, createdOn, expiresOn, collection and entryId. Workday pages through matches for you and downloads content only when a later step uses it.
  • Retrieve Document: give a collection and an entry ID and it returns the document content and its file name, ready for a Send HTTP Request or a transformation step.

Store Document's defaults matter here. In an Integration System orchestration, the collection is the integration event's WID and the document is not attached to the event unless you set Attach document to integration event to true. Set that flag when the file should be associated with the event as an output file rather than only sitting in a collection. Storage Expires In takes an ISO 8601 duration such as P7D.

Find Documents is available in the Integration System template and in suborchestrations; Retrieve Document is also available in the Business Process template.

If you only need run status, use Integration Insights

If the question is "did it run, how long did it take, did it fail", the Integration Insights REST API returns event data without SOAP: GET /integration/insights/reporting/v1/tenanted/raw on the API gateway, with startedAt, completedAt, eventType, limit (up to 10,000) and cursor paging. Each event has status, durationMillis, correlationId and processWid, which ties it to Process Monitor. It does not return documents, and Workday keeps the data for 14 days, so schedule regular pulls. In implementation tenants you have to select Insights Events Enabled in Edit Tenant Setup - Integrations first.

Push the file instead of pulling it

When an outside system needs the file, the documented route is for Workday to send it rather than for that system to fetch it. Store Document can deliver an event-attached document through the integration's configured delivery services, and an orchestration can send the content from Retrieve Document to any endpoint with Send HTTP Request. Either way the destination receives the file when the run produces it, and Get_Event_Documents remains available to check afterwards that the event recorded what was sent. Neither Get_Integration_Events nor Get_Event_Documents returns the content, so a design that has an outside system pull output files through those operations will not work.

Prove it

For one known run, compare three views of the same event: the event in the Workday UI with its output files, the Get_Event_Documents response for that event's WID (file names and sizes should match), and, if you read the content in an orchestration, the size of what Retrieve Document returned. If Get_Event_Documents returns nothing for an event that shows files in the UI, check that the documents were attached to the event and not only stored in a collection, and that they have not passed Expiration_Timestamp.

For comparing where this logic should live, see Workday Orchestrate vs Studio; for failed Studio runs, debugging a Workday Studio integration.

Sources checked