The modern HTTP Request activity does not correctly handle API responses that are compressed with Gzip. The activity automatically tries to decode the compressed binary data as a plain text string, which corrupts the response body. This makes it impossible to work with APIs that use Gzip compression.
The .TextContent property of the HttpResponseSummary object contains garbled data, and the .BinaryContent property remains empty, leaving no way to access the raw, uncorrupted response bytes.
Interestingly, I have tested this same API call in UiPath Studio Web, and it works correctly there.
Impact:
This limitation forced me to stop using the modern HTTP Request activity and instead switch to the legacy version. This defeats much of the convenience of the modern activity.
My suggestions:
To make the modern HTTP Request activity easier to use in scenarios involving compressed responses, it may be helpful to improve how compressed content is handled. For example:
Automatic decompression:
The activity could detect the Content-Encoding: gzip header and automatically decompress the response body before populating the .TextContent property. This would allow the response to be used directly without requiring additional processing in the workflow.
Alternative approach: exposing raw bytes:
If automatic decompression is not appropriate in all cases, another option would be to ensure that the .BinaryContent property contains the raw byte array from the response. This would allow users to perform decompression manually when needed.
Implementing either of these approaches could help make the modern HTTP Request activity more flexible and easier to use when working with APIs that return compressed responses.
Environment Details:
Studio Version: 2026.0.186STS (Community License) Package: UiPath.WebAPI.Activities v2.3.2 Project Type: Modern / Cross-Platform
Hello @Sasha_Basova and thank you for the detailed report on this matter.
First of all, to get around the issue you can expose the raw bytes by setting Always save response as file to true, under Response options section. This should read the raw bytes and save them to a file as is, no scrambling.
When you say " I have tested this same API call in UiPath Studio Web, and it works correctly there." what are you referring to, specifically? Is it their Workflow API? Or the same Http Request activity?
One more thing: you can always Enable debugging info, under the same category Response options and feed the raw output to any LLM of your choice. This can also be achieved while Testing the call at design time. The Autopilot in Studio, for example, should be great at figuring out what is happening there. Just ensure that you are not sharing any sensitive data as we are only redacting some parts that we know for a fact they are sensitive, like Bearer tokens or passwords.
If you manage to get around and try this, let us know how it went as it is an interesting use case.
We’ll be looking into this matter in greater detail in order to have the activity do automatic decompression.
Thank you for the guidance! I went around the issue by forcing the HTTP Request activity to save the raw binary response to a file, which I then processed using the Extract/Unzip Files activity. This fixed the “scrambled text” issue.
In Studio Web (API Workflow) The HTTP Request activity worked perfectly. It seems it automatically handles Content-Encoding: gzip headers. Studio Web (RPA Workflow) and Studio Desktop both did not decompress the response automatically, resulting in garbled .TextContent.
I am learning to connect UiPath to the SAP Business Accelerator Hub Sandbox (without a corporate SAP account), and the HTTP Request activity is my primary tool for integration.
