There are many errors that can occur during API integration in UiPath and in general. It is too long/difficult to cater for them individually. What I recommend you do is handle them in two high level branches, and then break each branch down further. For example:
Successful → Meaning that the API itself passed, but it might not have been 200, it could have returned any code you mentioned.
Fatal exception or general system Exception → Anything that you did not expect to occur, you can treat as a general system exception in your flow.
Under successful, I would look at your most common response codes:
200 = Success → continue with response
400 = Bad Request → your payload is incorrect.
401 = Unauthorized → You did not authenticate yourself
403 = Forbidden → Usually permissions or scope related (occasionally an expired token, depending on the API)
500 = Internal server → a server-side failure. Often temporary, so it’s worth retrying, but if it fails consistently for the same record, check your input data.
In modern RPA projects, the HTTP Request returns a response which has all information inside. You can filter through it to get the necessary details.
In my personal experience, I have only ever dealt with these types of issues above. However, one that I didn’t mention that pretty much ALWAYS occurs is the old tale “it works on postman but not in UiPath”. I recently completed a project 1 month ago where this became a HUGE blocker. I resolved it in two ways:
Requested the client to whitelist UiPath’s IP addresses for their region (Orchestrator etc.) → this resolved most issues.
We asked whether they had externally facing APIs. It turned out they had both internal and external endpoints for the same API, and the external one was exposed to the internet. With the client’s approval, we switched to the external endpoint, which removed the need for further whitelisting and let us move forward.
Remember, Postman and UiPath run in different environments. Postman runs on your own machine, usually inside the client’s network or VPN, while calls from UiPath’s cloud come from outside and have to get through the client’s firewall. If your robot runs on-prem, the call comes from the robot machine instead, so check its network, proxy, and firewall access.
@Abhinay_Reddy1 In real UiPath API projects, I’ve seen the usual HTTP errors, but the root cause is often more important than the status code itself.
A few common scenarios:
401 Unauthorized – usually expired/invalid bearer token, wrong client ID/secret, or token not refreshed before the API call.
403 Forbidden – authentication works, but the account/application does not have the required role or API scope.
400 Bad Request – incorrect JSON structure, missing mandatory fields, wrong date format, invalid datatype, or headers such as Content-Type not matching the payload.
404 Not Found – wrong endpoint, environment-specific URL, or trying to access a resource that was already deleted/doesn’t exist.
429 Too Many Requests – API rate limit reached. We handled this using retry with delay/backoff instead of immediately retrying.
500/502/503 – usually server-side or dependent-service issues. We first log the response body, correlation/trace ID, request details, and retry only when the operation is safe to retry.
Timeouts – sometimes the API actually completes on the server even though UiPath receives a timeout. For create/update operations, blindly retrying can create duplicate records, so we verify the result before retrying.
Token/session expiry during long processes – the process may start successfully but fail after running for some time. In such cases, token refresh should be handled centrally instead of generating a token before every request.
Success status but wrong/incomplete data – one of the trickier cases. We have seen APIs return 200 but the downstream system was not updated as expected. So validating only the HTTP status is not enough; the response content and downstream result should also be checked.
For troubleshooting, I normally log the endpoint, method, status code, response body, correlation ID, and relevant request details while masking passwords/tokens. Testing the same request in Postman also helps quickly identify whether the issue is from the UiPath workflow or the API/backend itself.
Hi @Abhinay_Reddy1 ,
In API projects, common issues are 401/403 authentication errors, 400 due to incorrect payload, 404 for wrong endpoints, timeouts, and 500 server errors. In UiPath, I usually capture the status code and response body from the HTTP Request and use Try Catch for proper error handling. For token issues, verify or refresh the authentication token and check the required scopes/permissions. UiPath HTTP Request supports API calls, authentication headers, and retry/error handling.
APIs will have same response codes and similar error information in all the tools.
You can find almost all the response codes in this Wikipedia page: List of HTTP status codes - Wikipedia
Basically, in real world scenarios, the issues are figured out and fixed through error codes and the actual error you get while running the HTTP Request activity in UiPath.
In my UiPath projects, I have faced different API-related issues, mainly:
400 – Bad Request: Incorrect request body, parameters, or headers.
401 – Unauthorized: Expired/invalid token or incorrect credentials.
403 – Forbidden: User/API does not have the required permissions.
404 – Not Found: Incorrect API endpoint or resource not available.
405 – Method Not Allowed: Incorrect HTTP method such as GET/POST/PUT.
408 – Request Timeout: Server did not respond within the expected time.
409 – Conflict: Duplicate or conflicting data.
415 – Unsupported Media Type: Incorrect Content-Type or request format.
429 – Too Many Requests: API rate limit exceeded.
500 – Internal Server Error: Issue on the API/server side.
502 – Bad Gateway: Gateway received an invalid response from the upstream server.
503 – Service Unavailable: API/server temporarily unavailable.
504 – Gateway Timeout: Upstream server took too long to respond.
Apart from HTTP status codes, I have also seen token expiration, SSL/certificate issues, connection timeouts, invalid JSON responses, missing/incorrect headers, and API response format changes.
In UiPath, I usually troubleshoot these by checking the HTTP status code, response body, request headers/body, logs, and API documentation. For temporary issues such as timeout or 5xx errors, a controlled retry can also be useful.
