Postman Enterprise Reviews

We use Postman for API testing only. We test it locally and share contracts with other teams. We also enter environmental variables to test different environments.

The environment variables are a valuable feature because I can easily switch them and see all the developments in different cycles and stages. I can deploy it locally and QA everything in different environments. 

I can copy the cURL request from the browser when browsing any website, copy the network tab from the browser and import it to Postman instead of rewriting everything, which comes in handy when debugging. If I'm working with a complete browser-deployed app, I can open a specific URL and see the recursion. 

One area that could be better is collection management. I duplicate collections and end up with lots of them. Maybe I'm not using it properly. But a better way to manage and save collections would be an improvement.

Another improvement would be the ability to clone a collection (or even have cloning as the default) to avoid time-consuming production issues.

We've been using the product for three or four years.

Postman is pretty reliable. I haven't encountered many stability problems.

Only the client can test it. I do not see much use for scalability. For example, if I have all these collections, I can use some script and automate the flow. Other than that, we don't see many use cases for Postman itself. 

So far, we've had no issues with Postman that required support because we just make an HTTP call and show the results. So we can get all the support we might need from sites like Stack Overflow.

The initial setup was straightforward with a little complexity.

Implementation was done in-house only.

We tried some different solutions after using Postman, not before. But Postman has better graphical support than its peers. At that time, I tried using a product whose name I can't remember ("Fire" something, I think) and others but had problems with them, so stopped.

I would rate this solution eight out of 10.

Regarding our relationship with the vendor, as far as I'm aware, the company has no business relationship with Postman. We use the product because it's the world's most commonly used open-source tool for repair testing.  

Regarding the number of staff required for the daily maintenance of the solution, we only make changes when the Postman tool or the contract changes. API contracts are modified daily. Most staff members continually modify or update these collections. Our developers use Postman at least once a day when developing.

My advice for others looking to implement Postman in their companies is that there is no reason to implement Postman. Plenty of other solutions are available, but most people are familiar with Postman because it appears in several YouTube tutorials. 

We use Postman for testing and documenting APIs. I'm the technical director. 

Postman helps me recreate our client environment so I can send different parameters and get that authentication information. Postman helps me simulate the API code from a fictitious client application so that I can check the API behavior. It gives you a good ecosystem, especially when you have a multi-discipline team that is scattered. It's a great product, easy to use, and people like it. 

I think they could make version management easier and release it when it comes to container-based or Docker-based architecture. The solution is not really integrated in the sense that there's no distinction regarding single-tenant or multi-tenant use, or whether there are different versions for different container applications. Different versions of APIs might be required but there's currently no distinction between them. 

I think Postman should now focus on integrating into the whole DevOps and CI/CD pipeline and publish more white papers and articles to make it easier for somebody doing the DevOps and integrating Postman into the different development scenarios. 

I've been using this solution for five months. 

The solution is very stable. We were able to test it and simulate different client experiences. 

The solution is scalable, we use it for millions of customers' API codes. 

We haven't needed to contact technical support because the documentation is very straightforward and very helpful. It has good community support.

The initial setup was straightforward and was carried out in-house.

We've been using the open-source version until now, but I think within the next six months we might move to the enterprise solution. Licensing costs are reasonable, in the mid-range. There are more expensive solutions. 

Postman has taken the development community by storm. A lot of developers are using Postman for different things. Not everybody understands the end-to-end capability of Postman yet; one person might think it's only for testing, another that you can build applications, and somebody else might use it for documentation. Different developers look at it from different perspectives, and it has huge versatility. 

I rate this solution nine out of 10. 

We usually do our API testing and the endpoint testing on Postman. That's our primary purpose for using Postman. Sometimes, we also use it for load testing, but most of the time, we use a different tool for that. 

I don't know the exact version that we are using currently, but most of the time, it is the recent one because our enterprise keeps on updating the software. In terms of deployment, it is a client tool.  

It definitely increases the quality of our deliveries because we are able to test our APIs before moving them to production.

We use it for REST API testing. Feature-wise, it is pretty lightweight. It is pretty fast, and we don't have to do a lot of things. We can just simply go and post our endpoint, and it gives different kinds of authorizations. We usually use authentication 2.0, which is the most common industry practice. So, it has the support for authorization through 2.0.

It gives the flexibility to add headers, and it also gives the flexibility to build your payload at run time. If you want to do automation testing, you can just build your payloads at run time by supplying some parameters as variables.

It gives us good flexibility, and it is pretty easy to use. Even entry-level developers can quickly test their APIs. They don't have to rely on the QA testers or the specific QA resources to look at various use cases.

The request encryption could be one thing on which they can work a little bit. If we don't want to expose our production data but we still want to test our APIs on the production data, there should be a way to do that. It is not only with Postman. I think no tool in the market is doing that right now.

It would be helpful if better tutorials or recommendations are available while we are using the product. Otherwise, we have to go out and search for specific things. It would be good if they build something in the tool itself that provides recommendations based on the task that we are doing. If we are testing APIs, the tool should come up with some kind of information.

Scalability-wise, it can be improved a little bit. They can include more options to do the performance testing or rate testing so that we can query or push a lot of requests to our APIs.

There could be some kind of graphical interface for performance testing. It would be really helpful if it can give some data to visualize how the performance testing is going in real-time, but there are specific tools for that. Postman might not be meant for that, but they can think on those lines.

I've been using Postman for almost four years.

I have never seen it crashing, which is a good thing for a tool like this. Sometimes, it hangs, but that's more of an operating system problem. It is not related to the application.

If we want to scale our operations, we definitely try to test our APIs with many requests at the same time from the real scenario perspective. For performance testing, we use a separate tool. NeoLoad is the tool that we use for our API performance testing. Scalability-wise, Postman can be improved a little bit. They can include more options to do performance testing or rate testing so that we can query or push a lot of requests to our APIs.

We are a very big organization. We probably have around 2,000 developers. It is being used extensively. It is good for API testing.

I haven't talked to anyone from their support team.

I started with SoapUI. It is similar in terms of capabilities and functions. There was no specific reason for switching to Postman. I saw people using Postman more, so I started using it. 

Postman is more popular than SoapUI. When we are doing testing of the APIs that we want to consume, people usually say that this is a Postman request, and you can try it out. More people use Postman than SoapUI, and that was the reason I started using Postman. 

It is pretty straightforward. They also have a WebUI. If you don't want to use it on your device, you can go and use WebUI.

It was done in-house.

It is doing what it is supposed to do. It is a pretty nice tool, and there should not be any problem in using it. It is definitely better than other alternatives.

Based on my experience so far, it is a flawless product. I don't see any bugs or any kind of technical issues in using it. It is pretty easy to use and easy to learn. If you want to start with API testing, you can go ahead and start with Postman. It is the easiest option available in the market.

I would rate it a nine out of 10.

I use Postman in my company for API testing.

Postman has a lot of additional features like the ones offered by SwaggerHub. Postman is a bit more complicated compared to SwaggerHub since you have to insert bearer tokens all the time and set everything from the start. I mainly use SwaggerHub as it is easy for me. I always get back to SwaggerHub from Postman.

Postman is a bit more of a complex tool, making it an area where improvements can be made.

Postman is good the way it is right now, so there's nothing to change in it.

I have been using Postman for a year. My company is a customer of the product.

It is a stable solution.

In my company, over 50 employees use Postman.

Given an opportunity, I would prefer to use Postman over SwaggerHub. People mostly prefer to use SwaggerHub over Postman.

The product's initial setup phase was easy and not difficult.

The solution is deployed on an on-premises model.

I would recommend others to use Postman. I am a QA, and I should know about different products before I use Postman. In short, a person should know to use it.

I rate the overall tool a nine out of ten.

We use this solution for every API development.

We are exploring code generation and how it works. We also like the test functionalities and snippets that we can use directly.  

Moreover, the tool is simple and easy.

Integration should be improved with our continuation system because we use Azure DevOps separately.

I have been using Postman for around two years. Initially, we used it only once, and now we use it more.

The solution is stable.

The solution is easy to scale till now.

We are using the solution for five people.

We get help from videos and the web.

Positive

We have also worked with SoapUI, but we like Postman because it has automation.

Postman is a more compact tool, and it has many functionalities. In the first stage that we used, Postman, we only tested how it works. Now we are using more functionalities. With SoapUI, it's because some customers have used it to define the APIs, and then we have to interact with this environment.

But we use Postman, and we prefer Postman. Although, there are some tools from SoapUI that are good. For example, the API design, checking, and definition. If Postman has anything similar, you can check the definition of the API, and it proposes you an improvement and so on, but in the development phase, we used Postman, and we like Postman.

The solution’s initial setup is easy. The maintenance is easy as well because we are not doing all the possible accents and because we are not doing anything to maintain.

The solution is deployed on the public cloud and on-premises in our organization. But I use it more in the cloud.

The solution’s pricing is realistic according to our usage level. As we grow and require additional functionality beyond what we currently use, there is a higher cost while upgrading the developer plan. We want to explore features like automatic code generation and other functionalities.

We are paying only for the license for now, and it comes with a monthly subscription.

Postman is one of the most widely used tools in the market. When you use it, it is practical and useful. You need to check whether it suits your team, project type, and work to take profit from the way Postman works. From the beginning, it is one of the three main tools you must explore if you regularly deal with APIs.

However, I am still exploring all the tools, and I don't know if I can maintain it or not. When I know all the different technologies better, I will be able to say.
Overall, I would rate the solution an eight or nine out of ten.

I'm using Postman for manual testing of REST APIs. There are some built-in collections done by some of my teammates, so I use those.

The solution is deployed on a public cloud.

I have used some parameterization from a global variable, so that was working fine for me. It's easy to see different versions of responses. There's also a possibility for automation.

We cannot do database connections from Postman directly, and we don't have a way to do that. If they could implement auto-validations and assertions from SoapUI, that would be a very good feature.

We don't have a provision to go and connect to the database from Postman. That's one drawback. If you want to automate in Postman, there is a major drawback. Being a tester, you always want to cross-verify your data with the database. If the database is not connected, then part of your testing becomes manual.

I have used this solution for about seven years.

It's stable. Sometimes it has gone off, and I have had to rebuild the collections again. I've had to switch the logins sometimes. It has crashed twice, and I lost my suites and had to build it again.

Initial setup is easy. Sometimes we get the proxy errors, but when we go to the settings and disable the proxy things, it's pretty simple. Comparatively, SoapUI is easier for me.

Maybe some people who don't have a licensed version of Postman or ReadyAPI might feel that it's easier to automate with Postman, but I'm not sure about that because I haven't done it.

I would rate this solution as four out of ten.

If you don't have SoapUI or if you don't know about SoapUI, then of course you can use it. If you want to explore Postman, it's a free tool.

Postman is a scripting tool.

I started using the solution when we did an SDN-based network implementation from Cisco. I got introduced to a particular scripting tool where I could actually put down everything in an Excel sheet. And if I want to configure, for example, ten ports, then I can actually do the configuration of everything in an Excel sheet. I can pass my credentials in Postman, and I can import the SQL script, and based on whether it's an infrastructure script or a configuration script, I can actually save it in Postman.

I'm using Postman to only push the scripts into the ACI, and that is a very limited use of Postman that we do right now.

I'm sure it might have other usages. That said, we have not explored other features beyond that at this point in time.

The initial setup is easy.

The solution is stable.

It is very user-friendly and has a nice UI.

My limited use of Postman has been to get the output of scripting in Postman or get the output from APIs and then open it in Postman or post the script. We don't use it much beyond that and therefore haven't really explored the features. It's hard to say what is lacking.

Postman does not have a check-in balance. Essentially what I mean by that is if there is something that is already configured on a particular device, it just overrides it without checking whether you really want to override it or not. Even if it is by mistake, if there is a dialogue box that is available before it overrides, it's just a much nicer feature to be notified if you're doing something by mistake.

I've been using the solution for a while. 

The solution is stable and reliable. There are no bugs or glitches. It doesn't crash or freeze. We haven't faced any issues.

I know that our team, which is three people, uses the solution. I'm not sure who else does in the company. We're all engineers. 

We have received all of the support we required. Postman has a very good team.

We use quite a few products from an infrastructure point of view. We use SolarWinds, both for server and infrastructure capacity, and we use a change management and a problem management tool. From a bandwidth monitoring perspective, we use a network analyzer; we use Splunk heavily. We do a lot of scripting tools using Postman and Python.

I'm more into Python since Python gives us many more API interjections and compatibility with a lot of other APIs. We started using Postman, and then we immediately moved to Python-based scripting.

The functionality that Python gives you concerning the available APIs and then the ability to put that in the Excel sheet is much better than Postman.

The solution is very easy to set up. There were no issues. 

I don't deal with the licensing aspect of the product. 

We looked into other solutions. However, Cisco actually recommended Postman, so we went with this product. 

I'm an end-user.

I'm not sure which version of the solution I'm using. 

New users need to watch a few videos and understand the solution pretty well. If you are using Postman for the first time, never use the administrative credentials. It is very easy for you if you're using the administrative credentials to pass through the Postman's scripts. It is possible that you might override the configuration unknowingly. If that happens, that can actually bring down a good amount of your configuration or an earlier configuration. It's best to actually get the solution into a development environment before you actually do anything on production.

I'd rate the solution seven out of ten. It's a good, very user-friendly scripting tool. Anybody can learn it and start using it. However, new users do need a little bit of knowledge and must be willing to learn as they go.

We use this solution for manual API testing, which we call penetration testing. Postman provides a user friendly interface that can be used by non-technical team members. 

It is easy and simple to use and install. It is compatible with Linux, Mac or Windows. Postman is a great solution and resource for those who are new to technical platforms in terms of API development and testing. Postman is an open source solution and so is an affordable resource for those wanting to learn. 

I would like to have a code snippet where I can write a code and for the responses of the endpoints to be validated using my custom business conditions. In certain scenarios, we want to have custom business scenarios and not generic ones. 

We would like to have a code interpreter in Postman and also for automation to be less complex. My team want various complex automations using APIs depending upon their complex business conditions but automation using Postman is limited.

The UI of Postman could be enhanced by adding a proper panel or code. 

I have been using this solution for five years. 

This is a stable solution but user rights can be complicated and cause disruptions. 

This is a scalable solution but scaling it can be complex. 

For support, we use the open communities and documentation provided.

The initial setup is very straightforward.

This is an open source solution.

I have previously worked in the airline industry and used ReadyAPI. This is a licensed product and was used to ensure GDPR requirements and data privacy policy requirements were met. This solution costs approximately 800 Euros. Postman, on the other hand, is free as it is an open source solution. 

Running test cases using Postman is not as easy as with ReadyAPI. 

I would rate this solution a seven out of ten.