Postman for API Testing: Your First Request and Useful Tests

Postman is an API client and testing workspace. Its practical value is being able to save a request, repeat it with a different environment and check whether the response still meets your expectations. You do not need a collection of hundreds of requests to start.

Send a request whose response you can understand

Create an HTTP GET request to this public demonstration endpoint. Do not include real credentials or private data:

https://postman-echo.com/get?source=netopsiyon

Send it and inspect the status, response headers and JSON body separately. The query parameter is part of the URL; it is not a JSON request body. A successful response should echo the demonstration argument. If the request fails, inspect the actual error before changing the request method or adding unrelated headers.

Turn an observation into an assertion

In the request's post-response script area, add these tests:

pm.test('Request succeeded', function () {
    pm.response.to.have.status(200);
});
pm.test('The demonstration argument was echoed', function () {
    const data = pm.response.json();
    pm.expect(data.args.source).to.eql('netopsiyon');
});

The second test checks response content rather than merely accepting any 200 response. These examples follow Postman's test-script API. A failure is information: distinguish invalid JSON, a missing field and an unexpected value. Avoid a strict response-time threshold based on one request over your home connection.

Keep environments obvious

Save the request in a collection. For your own API, define a non-secret base_url environment variable and reference it as {{base_url}}/health, using an endpoint your application actually provides. Give development and production environments unmistakable names. Check the active environment before sending requests that modify data.

Variables are not automatically a safe place for secrets. Use the appropriate credential storage and review sharing settings before exporting or publishing a collection. Postman's Vault documentation distinguishes local and shared secret storage. Do not put tokens into URLs, screenshots or saved example responses.

Build a small collection you can trust

For an application you control, add a normal request, an invalid-input case and an unauthorized case with their expected results. Use disposable test data for write operations and document cleanup. Before adding the collection to automated runs, make sure repeated runs do not create duplicate orders or delete shared fixtures. A short collection with clear assertions is easier to maintain than a large folder of requests nobody knows how to interpret.