Orchestrate Send HTTP Request Adds charset=UTF-8, Causing a Malformed 400 Error
What it means
When an Orchestrate Send HTTP Request step calls an external REST endpoint that expects application/x-www-form-urlencoded, Orchestrate automatically appends a charset=UTF-8 parameter to the Content-Type header. Some external systems reject that extra parameter and return a 400 error, even though the request body itself is fine.
Troubleshooting
- Confirm the external endpoint is failing specifically because of the Content-Type header, not the request body or auth, by replaying the same payload through a client that lets you set the header exactly (with and without the charset parameter).
- Check the vendor's API documentation for whether it explicitly rejects a charset parameter on this media type; some strict parsers do, even though the HTTP spec technically allows it.
- Confirm there is currently no configuration option in the Send HTTP Request step to suppress or override the charset parameter, since Workday does not expose one today.
- If the receiving system's team can make changes, ask them to ignore or strip the charset parameter on their side instead; that is usually the faster fix.
If the external system can't be changed, front the call with a lightweight proxy or relay endpoint that strips the charset=UTF-8 parameter before forwarding the request to the real destination.
Track this as a known Orchestrate platform limitation (there is currently no way to suppress the charset parameter) and raise a Workday support case referencing it if it blocks a production integration; Workday has indicated intent to address it based on customer demand.