What is your primary use case for Postman?

I use Postman to test REST APIs. I work with Node.js and create or modify multiple endpoints, and I use Postman to verify if the endpoints work. Additionally, I use Postman to test other endpoints, like public endpoints.

We have been using Postman primarily for API automation.

I have been using Postman for three years. I am not using the tool's latest version, Postman v10.11.1, but I am not sure. I think I am using the older version, Postman v9. I am just a customer of the tool.

I use Postman from time to time to test real-time API connections. When I receive documentation regarding API services, I use Postman to verify that the explanation in the documentation I received is working as described. In general, the tool is good for testing purposes.

I use Postman in my company for API testing.

I use Postman as a testing tool. I used Postman for one of the education-based applications named Compass. I can use Postman effectively.

We use this solution for every API development.

I use the tool to test the APIs that are developed.

We use the solution for API testing purposes.

We use the solution for rest API testing purposes.

We used the solution in multiple ways, including: 1. We create Rest APIs for the communication of the front end to the backend. For the testing of those Rest APIs, we use Postman. It provides a user-friendly platform for API testing with all the request methods like GET, POST, PUT, DELETE, PATCH, and many more. We can create our own collections like group requests. We can easily share the collection with the team. 2. We are using Postman to create the documentation of the REST APIs, which the backend team creates, so the frontend engineer can easily see the request type, headers, methods, and response body for the request. 3. It is also used as an API testing tool by the automation testing team. We can write our own tests with the assert statements in Postman after the response.

We are primarily using the solution for API testing. We do some automation and validation.

I primarily use Postman to manually test our APIs with HTTP and REST calls. I don't use the more advanced features, such as script automation.

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 am working for an insurance firm, a big client in the USA. They wanted to upgrade the current technology with something new. However, they have legacy applications, and they don't want to handle APIs. They didn't want anything to hit their existing API since they have two layers of APIs. At the same time, there are different components with around 17 to 18 integrations and various applications. We wanted one tool that could help us handle the restrictions and the implementation. This is both an API and a very helpful testing tool. It's user-friendly for everyone using it in a big firm.

Postman is a good tool for completing a sanity check or smoke test of REST APIs. It's a quick way to manage your REST API-related test cases, and it gives good options for assertions for the response of the APIs. We have 30 people using this solution in our business.

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.

We are using Postman to verify and test APIs.

There is a regular set of use cases, such as basic logins and long-form fills and submissions. There is a regular data set that we pick from the APIs, mostly with the GET, POST, and PUT calls. These are the three API methods we use regularly. We are using the local version of Postman that we download for manual testing of the API. We do the automation directly in REST Assured with Java.

We primarily use the solution for testing and preparation of the base URL which I generated for the first tokenization. I prepare the test suite and the XML or Java core that give the input parameters. The major role is the pre-requisition of the scripts in Postman - which is mandatory. We can input parameters into Excel and execute for the application. We work in many environments, including QA, SAP, production, pre-production, and proof. We use Postman for each and every release. Before anything goes to the master branch in GitHub, I'll completely check the code and unit test the complete scripting. I'll execute it one or two times, and once it's stabilized, I'll directly deploy it to the master branch.

Our company uses the solution for single user regression testing of APIs. For each of our releases, we run a regression report that includes APIs contained in that release. We create structure suites by importing API information from swagger links, writing test scripts for APIs, and validating the values in our responses. This process can take some time but completed ignition suites can be reused.

Postman is an API regression suite, and we design different workflow center processes. We maintain the Postman tool and add JavaScript applications. Since it is not that robust, like ReadyAPI, we have to write many scripts to support it.

I use Postman for API testing. I use this solution for UI or automation purposes.

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.

We use this solution to create multiple automations for a number of different users.

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

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.

When critical things happen, and we need immediate testing, we use Postman or SoapUI. For example, when testing ServiceNow applications, we use Postman to call the APIs. The data sequence of the APIs has to be called, so we create test cases in Postman that call the appropriate data, authentication keys, and everything else we include in the data. And when we post about it, we include all that data. We fill in all of the required fields and send the request. When we get the response, it will include some data. We capture that and send it along on the subsequent request. So we usually use Postman to keep our directors informed during our integration and product testing. It's a pretty mature solution. Postman is about seven to eight years old.

We mostly use a REST API for testing related to third-party applications, integrating services with third parties responsible for food delivery. Use cases include onboarding for when a new store opens, uploading the menu on the third-party app. and an API for customers to order from a menu. We also use Postman for payments, whether debit or credit card. It covers all the validation points, including whether a card is fake, stolen, invalid or blocked. We are customers of Postman and I'm a senior consultant.

We use Postman for testing and validating API's. Used it for testing, debugging and validating SOAP and HTTP API's.

We use it for our APIs. We also use it for automated testing.

We use Postman for testing the functionality of REST APIs. Within my organization, there were roughly five people using this solution, however, currently, I am the only person who is developing API testing tools.

We are using Postman for our testing and checking our API response and validations.

My primary use case is for responses. I'm a user and work as a programmer analyst.

Our primary use case for Postman is API testing for our product. We haven't automated the request and response part yet, like how we used to do for automation scripts. Basically, we are just shooting the URL's and recording the response. As of now we have multiple API's and we are using the collection so that we can run it together in a single flow, like an automation execution. Then we use the basic variables and the collection variables. We even saw that we have some additional validation through the response code and the status code, like if there is an expired date then we should be expecting 200 status codes. We are doing those kinds of things now. We have been using Postman for the API testing for two to three month.

My primary use case is for API testing.

Almost all the teams here depend on the APIs, which are built-in SOAP or JSON. We have multiple teams testing JSON and they use Postman. There are multiple applications teams that integrate their interfaces with APIs, and they use the Postman.

We are using it to test the API service for the GET and the POST. For this type of test, it is working properly for the APIs. It tests for the minimum usage of Postman. Also, if developers insist in collections, then we can share these collections as well.