Problems with request to API with content-type x-www-form-urlencoded

0
I am trying to consume a REST API that requires me to send a request with content-type x-www-form-urlencoded. I have configured the 'Call REST' activity with the correct endpoint, used 'Custom request template' for the, well, custom request and added everything in there, neatly separated by ampersands and equals-signs (i.e. grant_type=abcd&subject_token=1234), but the API returns errors that leads me to believe it can't interpret the payload.Does Mendix URL-encode the request for me, or do I have to do that by hand myself?Because I have tried encoding the whole request by hand, replacing all reserved non-alphanumeric characters with their percent-encoded variants (':' to `%3A`, '=' to `%3D`, etc.), but to no avail.Then I tried encoding both the reserved and the unreserved, non-alphanumerical characters (like underscores), but that also didnt work. Then I tried adding everything as query parameters to the endpoint, both encoded and unencoded, and even a combination of URL parameters and a custom request template, but that didn't work either.I'm kind of running out of options here...
asked
1 answers
0

Yes, Mendix can do this, but for application/x-www-form-urlencoded the setup has to be very specific.


What usually works is:


Use a normal POST Call REST, add a custom HTTP header

Content-Type = application/x-www-form-urlencoded

and in Request choose Custom request template with a body like:


grant_type=abcd&subject_token=1234


That is the pattern described in the Call REST docs for a custom plain-text body, and it is also the approach confirmed in multiple Mendix forum answers for form-urlencoded requests.


A few important details:


First, do not percent-encode the whole string.

You should only encode the values that need encoding, not the separators themselves. So = and & must stay as they are, otherwise the server can no longer parse the form body correctly.


Second, do not use query parameters for this unless the API explicitly wants them in the URL.

For x-www-form-urlencoded, the server normally expects the parameters in the request body, not in the endpoint URL. Forum examples that worked in Mendix used a POST body built with a custom request template, not export mappings or form-data.


Third, make sure the header is exactly:


application/x-www-form-urlencoded


not just x-www-form-urlencoded. That exact header value is what Mendix community examples report as working.


One more thing to keep in mind: if you are on an older Mendix 10 version, there was a known issue where custom request template bodies were serialized with ISO-8859-1 instead of UTF-8. That was fixed in Studio Pro 10.18. If your payload contains special characters, upgrading could matter.


So my recommendation would be:


Set the request as POST, add the exact Content-Type header, use Custom request template, and send:


grant_type=abcd&subject_token=1234


If a value can contain spaces, +, :, /, = or similar characters, encode that value only before putting it into the template.


If it still fails after that, the next thing I would verify is whether the API also expects an Accept header, an Authorizationheader, or a very specific parameter name/order, because at that point the problem is usually API-side expectations rather than Mendix not supporting the format.


If this resolves your issue, please mark it as accepted.

answered