HTTP Activity in UiPath Studio

Help Studio
1

Hi,

I’m using an HTTP activity to download an attachment from the ServiceNow portal. Over the past few days, it worked as expected and saved the file in the designated folder based on the properties panel settings.

However, recently the downloaded file has been getting corrupted after the download completes. Does anyone know what might be causing this issue?

image
image1283×551 46.2 KB

image
image587×693 26.2 KB

2

Have you confirmed that the file is not corrupted in the source?

3

Hi @Ragul_Kannan,

Could you check a few things:

  • Verify that the API is still returning the correct file and not an error message or HTML page.
  • Compare the file size of the downloaded file with the expected file size from ServiceNow.
  • Check the HTTP response status code and headers.
  • Try adding a small delay after the download completes before processing the file.

Thanks

4

Hi @Ragul_Kannan

he API was returning an error/JSON response instead of the actual attachment due to an authentication issue, and the saved file appeared corrupted.

Could you check:

  • HTTP Status Code (200 OK)
  • Content-Type header
  • Downloaded file size vs original file size

Also, try testing the same API in Postman to verify that the attachment content is being returned correctly.

Happy Automation

5

@Ragul_Kannan

Were there any upgrades or changes made?

Is there any change in reesponse or type of files

Cheers

6

@Ragul_Kannan I would suggest checking the below points:

  1. Log the HTTP status code
    • Make sure the response is 200 OK.
    • If it is 401, 403, 404, etc., then the downloaded file is not the actual attachment.
  2. Check the response headers
    • Verify Content-Type.
    • For a real file download, it should be something like binary/octet-stream or the actual file MIME type.
    • If it is text/html, application/json, or application/xml, then you are saving an error page/message as a file.
  3. Do not hard-code the extension
    • In your screenshot, the file is saved as .xlsm.
    • Make sure the actual ServiceNow attachment is also .xlsm.
    • If the original file is .xlsx, .pdf, .csv, etc., saving it as .xlsm can make it appear corrupted.
  4. Check authentication/session
    • Since it worked earlier and recently started failing, the token/session/permission may have changed or expired.
    • Try opening the same attachment URL in browser/Postman with the same credentials and confirm whether it downloads correctly.
  5. Validate file size
    • Compare the downloaded file size with the actual attachment size in ServiceNow.
    • If the downloaded file size is very small, it is likely an error response, not the real file.

In my opinion, first log the status code, content type, and response body/size. That will clearly show whether UiPath is receiving the real attachment or an error response from ServiceNow.

7

Yes I am confirmed while download the file and open using Postman it opening as expected

8

Hi @Ragul_Kannan,

check if the authentication behavior or response interpretation might be different between the activity and postman.

  • Missing headers: Authorization (Bearer / Basic / OAuth), Cookie
  • Enable AllowAutoRedirect = True
  • Verify TLS mismatch: System.Net.ServicePointManager.SecurityProtocol → ServiceNow might enforce TLS 1.2 or higher
  • Check how you interpret the response: e.g. String instead of Byte[]

Also like @Dhruba_Jyoti_Kalita is suggesting, I would do the following:

  • Verify responseHeaders("Content-Type") and responseHeaders("Content-Length") → even with status 200, it might still return HTML (e.g. text/html → you’re downloading a login/error page)
  • Verify the file-extension. Mismatches can cause files to appear corrupted even if the content is correct

For better reliability and troubleshooting, consider creating a reusable template for your HTTP requests that includes:

  • Logging of critical information:
    • Status code
    • Response headers
    • Response size
  • Explicit handling of different status codes: 200 (ok), 201 (created), 409 (conflict, e.g. creating orchestrator assets, but they already exist)
  • Safe parsing of response data (e.g. JSON) using Try-Catch blocks in case fields are missing. Place them individually, so you definatelly know where the issues are
  • Throwing meaningful exceptions based on response conditions
  • Implementing retry logic where appropriate (e.g. for transient failures)
9

Hi @Ragul_Kannan,

Could you try running the automation and checking the Windows Event Viewer and UiPath logs to see if any errors are reported during the download process?

Thanks