1. My goal:
Send a Raw request body from a Retool query to an endpoint that expects the body to be received as a string, even though the body content itself is JSON-shaped text.
2. Issue:
Until today, this worked without explicitly setting a Content-Type header. The Retool query sent the raw body correctly and the endpoint received it as a string.
Since today, the same query appears to send or transform the body differently, causing the endpoint to treat the body as JSON instead of a raw string. This breaks the request because the endpoint expects a string body, not a parsed JSON object.
Adding the following explicit header fixes the issue:
Content-Type: text/plain
After adding this header, the endpoint receives the body correctly again as a raw string.
It feels like Retool may have changed the default behavior for raw request bodies when no Content-Type header is provided, or it now infers application/json when the raw body contains JSON-shaped text.
3. Steps I've taken to troubleshoot:
Confirmed that the endpoint still works when called with a raw string body.
Confirmed that the issue only happens when the request body contains JSON-shaped text and no explicit Content-Type header is set.
Added Content-Type: text/plain to the Retool query headers.
After adding this header, the request started working again.
No backend changes were made on our side that would explain the behavior change.
Hey @avr - thanks for reaching out. This is likely related to a flag that we started ramping recently, but have since rolled back. We're in the process of replacing a problematic backend library and this is a feature gap that will need to be addressed before we make the transition.
Can you confirm that your REST API queries are working without a Content-Type header?
I don't know if it's a similar issue, but I've just hit something that feels related to the behavior change you described.
I'm uploading files to S3 using presigned POST requests with multipart/form-data. Until recently, this worked without explicitly setting the Content-Length header — Retool would handle it automatically.
Now I'm getting the same kind of error on the other end:
Error: MissingContentLength — You must provide the Content-Length HTTP header
The catch: Unlike your scenario, I can't manually set Content-Length because Retool calculates the multipart boundaries during encoding. When I try to set it manually, I get:
Request body length does not match content-length header
It seems like Retool may have changed how it handles headers/encoding for requests with dynamic payloads — first with Content-Type inference (your issue), now with Content-Length for multipart. Postman calculates this correctly without any manual intervention, so it feels like Retool's auto-header behavior has regressed.
The same request that worked a few days ago now fails. Has anyone else experienced this with file uploads or multipart requests? Any workarounds?
