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.

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. 

I use Postman for API testing and plan to start using it for automation testing.

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.  

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 use the solution for rest API testing purposes.

The primary use case for the solution is to test the response accuracy of services that we hit without the UI.

Our developers use the product for unit testing and integration testing. Our QA team uses it for functional testing where we measure the performance of the scripts written in Javascript. We also rely on JMeter so that we don’t need to spend double the time on rewriting those tests again.

For example, contract testing will have scenarios that will contain around 20 API calls. After the login, you can create the data, edit or delete it, verify the changes, and log out. This will be one test case. There will be around 20-30 test cases. The script file will contain around 30 test cases written in a row.

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.

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 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 Postman for testing and documenting APIs. I'm the technical director. 

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 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. 

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.

We use this solution for every API development.

The primary use case of this solution is for the API manual testing, manual verification to get the response, and for API automation.

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. 

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. 

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.

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.

I use Postman in my company for API testing.

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.

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.

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

We use the solution for API testing purposes.

The main reason we are using Postman is for checking and validating the API whether it works fine or not. When they send a request, we will receive the response with a successful code or we will be monitoring the code number for the latest number record.

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

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

We are using Postman to verify and test APIs.

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

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. 

The solution is used for testing APIs, building monitors, and scheduling everyday runs to check API health.

We're a big organization. I'm not sure how many employees we have, but everyone on our team uses Postman. We use Postman mostly to do API testing for a U.S.-based telecom company. I work in a middleware layer, so we get a lot of events from some other subsystems. Events are sent to a particular pipeline comprising Rabbit MQ and Kafka. It's not possible for our organization to simulate the events, like in a QA environment. It's not easy to create those events because they are sent by other companies or other systems.

Using Postman, we simulate these events by sending the events to that particular pipeline. Then we have a consumer application attached to that pipeline. When this particular event is triggered, it's captured and sent to Kafka, so we get a response in a system. It's basically a simulation. Some people try this in our organization itself. For my part, it's more on the DB side. 

Our primary use case is for API testing and I focus on automation.

I use this solution in my personal capacity. I use this solution to manage APIs. 

I am using Postman for API tests.

We used Postman to test APIs before implementing them. We used the latest version of Postman, and it was deployed on a private cloud, AWS.

We are using Postman for testing APIs. It is simple, easy to use and a good tool.

Our company uses the solution for API testing. We have forty users who are trained in-house for various projects. 

Our company uses the solution as a developer platform for testing APIs. Our backend team develops APIs which are then pushed to the solution for QA testing and configuration. 

We use it for our APIs. We also use it for automated 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.

Our primary use case for the solution is data-driven testing for API. We get data from the environment, and we have some APIs to get the data.

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.

We use the solution for API testing. 

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.

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 API testing.