Studio HTTP-Out Step Returns 500 BadRequestException After a Set-Headers Step
What does "com.capeclear.mediation.MediationException: Http Out" mean in Workday Studio?
When a Set-Headers step runs before an HTTP-Out step, it can silently overwrite or drop the Content-Type header a downstream REST API needs, even though the same payload works fine when tested directly in a tool like Postman. The receiving API then rejects the request as malformed and returns a generic 500 rather than a header-specific error.
Quick fix
Explicitly set the Content-Type header in the Set-Headers step's properties rather than leaving it to default, and confirm the Output property targets the header part, not the message body.
Permanent fix
Add an explicit header-verification step (or log the outbound headers) before any HTTP-Out call added after a Set-Headers step, so a silently dropped or misdirected header is caught in testing rather than surfacing as a generic downstream 500.
Troubleshooting
- Compare the exact headers Studio sends against the headers that worked in Postman, don't assume Studio replicates a client's headers automatically, check the HTTP-Out step's actual outbound request in a network trace or debug log if available.
- Check the Set-Headers step's Output property, setting it to the wrong message part (for example rootpart when the transport expects a header part) can prevent the header from being applied to the outgoing request at all.
- Explicitly set Content-Type in the Set-Headers step rather than relying on a default, some transports don't infer it from the payload body the way a browser or Postman does.
- Confirm the receiving API's actual required Content-Type value (application/json vs. a vendor-specific variant), a generic 500 from the far side often hides a more specific header-mismatch complaint.