Workday Out Returns invalid username or password After an Upstream External API Call Left Its Headers Set
The error Integration Failed. com.capeclear.mediation.MediationException: application=<APP_NAME> - Workday Out transport id=IntegrationsWebServiceNoStoreMessage encountered problem sending to endpoint 'https://<HOST>/ccx/service/<TENANT>/Integration_Metadata/v20' with operation 'Put_Integration_Message_Request'. Details: MSG_SENSITIVE:<GUID> application=<APP_NAME> - Code: SOAP-ENV:Client.authenticationError, Reason: invalid username or password Root Cause: BadRequestException :
What does "Integration Failed. com.capeclear.mediation.MediationException: Workday Out transport id=IntegrationsWebServiceNoStoreMessage" mean in Workday Studio?
An integration that calls an external API and then writes back to Workday fails on the internal call with an authentication error, even though the integration system credentials are correct. Headers set for the external call are still on the message when the Workday Out step runs, and they override the credentials the transport would otherwise supply.
Quick fix
Insert a step that clears the inherited HTTP headers, in particular Authorization, immediately before the Workday Out step, then rerun.
Permanent fix
Scope headers to the call that needs them. Set them as late as possible, directly before the external request, and clear them directly after it, so no internal Workday call can ever inherit an external system's Authorization header.
Troubleshooting
- Read which endpoint actually failed. This message names an internal Workday service such as Integration_Metadata, not the external system, so the credentials under suspicion are the integration system account rather than any vendor key.
- Check the Signon and Attempted Signon report for the integration user around the failure time. If there is no failed signon recorded, the request never presented those credentials, which points at the message rather than at security.
- Walk the assembly backwards from the failing step and list every Set Headers step on the path. An Authorization or Content-Type header set for an external call stays on the message until something removes it.
- Pay attention to steps that only run on some routes. A logging or debug branch that skips the external call will pass while the live branch fails, and that asymmetry is the clearest signal that state is being carried, not that configuration is wrong.
- Note that copying components between assemblies or renaming a project can reshuffle step order and reintroduce this without any visible edit to the steps themselves.
Was this helpful?