I’m learning API integration in UiPath and I understand that Postman is a separate tool mainly used for API testing, while UiPath uses activities like HTTP Request to integrate the API into the actual automation.
I’m curious to know how experienced UiPath developers use Postman in real projects.
Is it mainly for testing the API before implementing it in UiPath, or do you also use it during development and production support—for example, troubleshooting, testing different payloads/authentication scenarios, understanding JSON responses, debugging issues, etc.?
If you could share some real-world examples of how Postman fits into your UiPath development workflow, that would be really helpful.
Hi @Abhinay_Reddy1 ,
Yes, experienced developers mainly use Postman to test and validate APIs before and during UiPath development.
You can use Postman to check the endpoint, authentication, headers, payloads, status codes, and JSON responses. Once the request works correctly, configure the same details in UiPath’s HTTP Request activity, which supports methods such as GET, POST, PUT, PATCH, and DELETE.
For APIs related to the UiPath ecosystem, such as Orchestrator and Test Manager APIs, I would prefer using Swagger. UiPath provides Swagger documentation for its APIs, and you can authorize and execute the API directly from Swagger without having to manually configure everything in Postman.
Postman is useful when working with third-party APIs, especially when Swagger documentation is not available. You can use it to test the API first, try different payloads and authentication methods, understand the response, and troubleshoot issues before implementing the API in UiPath.
Setting up the API in Postman can take some time, whereas in Swagger, you can simply click the Try it out button and test the required API.
So, in my experience: UiPath APIs → Swagger first; third-party APIs → Postman is often very useful for development and troubleshooting.
Thank you for sharing this. I learned something new about using Swagger for UiPath APIs, especially for APIs like Orchestrator and Test Manager. I really appreciate you sharing your experience and teaching me something new. Thanks again!
In real-world projects, I’d say Postman is useful throughout the API integration lifecycle, not only before development.
A typical workflow is:
Explore the API in Postman – understand the endpoint, HTTP method, required headers, authentication, parameters, and request body.
Validate the response – check status codes and understand the JSON structure before building the UiPath workflow.
Test different scenarios – try valid/invalid payloads, missing fields, authentication failures, and different input values.
Implement in UiPath – once the API behavior is confirmed, replicate the required request configuration using HTTP Request / API activities and deserialize the response as needed.
Troubleshoot production issues – Postman can help determine whether an issue is with the API itself or with the UiPath implementation by sending the same request independently.
For example, if an API call works in Postman but fails in UiPath, I would compare the URL, headers, authentication, content type, payload, and response between the two requests. This makes troubleshooting much easier.
So, Postman acts as a useful API development and troubleshooting tool, while UiPath handles the API call as part of the actual business automation.
Postman is used throughout the project lifecycle, not just before development. Before building anything, developers use it to confirm the API works with the given credentials, sort out authentication such as OAuth tokens and scopes, and work out query parameters (Example: SuccessFactors filter parameters like “$filter” and “$expand”). The sample responses saved at this stage then guide how the JSON is parsed in UiPath.
During development, payloads are perfected in Postman first and then ported into the HTTP Request activity, which is much faster than rerunning the bot for every change. Developers also deliberately trigger error responses such as 401, 404, 429 and 500 to decide how the bot should classify and handle each one.
In production support, Postman is the quickest way to isolate a failure. If replaying the failing request fails in Postman too, the problem lies with the API, credentials or data, but if it works, the problem is in the bot’s implementation. It’s also handy for checking expired credentials and for Orchestrator API tasks like looking up queue items or job status. Many teams keep shared collections with separate Dev, UAT and Prod environments and attach them to SDDs so support teams can test without opening Studio. A good rule of thumb is that if a request doesn’t work in Postman, there’s no point debugging it in UiPath.
@Abhinay_Reddy1 Aside from testing endpoints and payloads, Postman is really useful in a few practical ways during development:
First, if you use Integration Service, you can export your tested Postman collection and import it directly under Custom Connectors. It automatically generates the activities, connections, and token handling without you having to build manual HTTP Request flows and deserialization.
Second, Postman Mock Servers are a lifesaver when the client API is still being built or stuck behind firewall requests. You can build the full workflow against mock responses and swap the base URL asset later when access is granted.
Also if you write Coded Automations in C#, clicking the code snippet icon in Postman gives you the exact HttpClient code ready to paste into your file, which saves a lot of time on boilerplate.
Here I’m sharing my experience as a UiPath developers use Postman in my real project.
About 4 years ago, I worked on a project where I needed to retrieve data from Salesforce and push it to the Google Marketplace. At that time, integrating Salesforce with UiPath was a bit challenging, so I developed custom APIs in Salesforce. I first tested those APIs in Postman to ensure the data was being returned correctly. Once the API responses were validated, I integrated them into UiPath using the HTTP Request activity.
In some scenarios, access tokens need to be generated dynamically during every BOT run. To achieve this, you must first call the token API and then use the generated token for subsequent API requests. The challenge is understanding how to test this flow and retrieve the token in real time within UiPath.
I’m sharing a video link that demonstrates how to generate and test access tokens in Postman in real time. It may help you better understand the process and implement it in your UiPath solution.
If this example helps you, please mark it as a solution.
Use Postman to make sure the API works, then build it in UiPath.
In my experience it goes like this:
Test the request in Postman first (URL, method, headers, auth, body) until you get a 200 response.
Look at the JSON response so you know which values you need to read later with Deserialize JSON.
Try a few wrong inputs too, like a bad token, so you know what errors (401, 404, 500) to handle in your bot.
Then build the same call with the HTTP Request activity.
One tip that saves time: in Postman, copy your request as cURL. The HTTP Request activity has a cURL import option, so you can paste it and the URL, headers and body get filled in for you. No need to retype everything.
Also, if something fails later in production, send the same request from Postman. If it fails there too, the problem is the API or credentials. If it works there, compare it with what your bot is sending, because the difference is usually in the headers, body or token.
Great question — in my experience Postman is the first place I go before touching UiPath. I use it to prove the auth flow works and to see the raw JSON responses, because debugging a 401 inside an HTTP Request activity is painful compared to seeing it instantly in Postman. During development I also keep a Postman collection per project with all the endpoints and sample payloads, so when something breaks in production I can re-run the same call outside UiPath and tell in seconds whether it’s the API or my workflow. One tip: export the working request as cURL from Postman and use it to double-check your headers and body in the UiPath activity — it saves a lot of trial and error.
