Build a Postman Collection

Organise HTTP requests for a real public REST API into a structured Postman collection — covering CRUD operations, query parameters, headers, request bodies, and saved example responses — to hands-on QA standard.

Role

Manual QA engineer

Difficulty

Beginner

Time limit

~60 min

Scenario

You have been asked to set up a Postman collection for the Reqres.in public API so the QA team has a shared, organised starting point for API exploratory testing. The collection should group requests by resource, document the purpose of each request, and include saved example responses that teammates can reference when the API is unavailable. Your task is to build this collection from scratch, covering the Users resource with CRUD-style operations and the Auth resource (login), and to annotate each request so a new team member can understand its intent without reading the API documentation.

Requirements

1.Create a Postman collection named 'Reqres API' with at least two folders: 'Users' (containing GET list, GET single, GET 404, POST, PUT, PATCH, DELETE requests) and 'Auth' (POST login — success and failure)
2.For every request, set the correct HTTP method, the full URL using base URL https://reqres.in, any required query parameters, and the correct Content-Type header; POST/PUT/PATCH request bodies must be raw JSON
3.Add a description to each request (using the Postman description field, not only the request name) explaining its purpose in 1–2 sentences, including what response status code is expected and why
4.Save at least one example response per request for: GET /api/users (list), GET /api/users/2 (single), GET /api/users/23 (not found), POST /api/users (create), POST /api/login (success), POST /api/login (failure)
5.Verify the actual HTTP status code for every request and confirm it matches the documented expectation; note any discrepancy between expected and observed behaviour
6.Export the completed collection as a JSON file (Postman Collection v2.1) and produce a request inventory listing: request name, HTTP method, URL, expected status code, and a one-sentence purpose note

Starter data

›Base URL: https://reqres.in — no API key required; all endpoints return realistic fake data and mutations are simulated (no real persistence)
›Users endpoints: GET /api/users?page=2 (paginated list, 200), GET /api/users/2 (single user, 200), GET /api/users/23 (not found, 404, empty body), POST /api/users (create, 201), PUT /api/users/2 (full update, 200), PATCH /api/users/2 (partial update, 200), DELETE /api/users/2 (delete, 204 no body)
›POST /api/users sample body: { "name": "QA Engineer", "job": "API tester" } — response includes server-generated id and createdAt timestamp
›POST /api/login success body: { "email": "eve.holt@reqres.in", "password": "cityslicka" } → 200, { "token": "QpwL5tpe83ilfWH2" }
›POST /api/login failure body: { "email": "peter@klaven.com" } (password omitted) → 400, { "error": "Missing password" }
›Saving examples: run the request, scroll to the response panel, click 'Save as Example' — the example is stored under the request and shows the exact status code, headers, and body captured at that moment

Expected deliverables

✓Exported Postman collection JSON (v2.1) with at least two folders (Users, Auth) and all specified requests
✓Request descriptions added to all requests (1–2 sentences each including expected status code)
✓Saved example responses for all 6 specified request/scenario combinations
✓A request inventory document: request name, method, URL, expected status code, one-sentence purpose note
✓Notes on any observed discrepancy between expected and actual status codes, with a one-line explanation

Evaluation rubric

Dimension	What reviewers look for
Collection organisation	Are requests grouped by resource or domain so a new team member can find 'create a user' or 'failed login' without reading every request? A flat list of 10 requests with no folders is not organised. Folders named by resource (Users, Auth) with descriptive request names — e.g. 'GET /users — single (found)' and 'GET /users — single (not found)' — make the collection self-navigating without opening each request.
Request correctness	Does every request use the correct HTTP method, URL, and headers? POST/PUT/PATCH requests must have Content-Type: application/json and a valid JSON body. A GET request with a request body, or a POST without Content-Type, is technically incorrect and produces misleading results when the collection is shared. DELETE /api/users/2 should have no body.
Saved example quality	Do saved examples capture the correct status code and a representative body? An example for GET /api/users/23 must show status 404 with an empty body '{}' — saving it after a 200 response invalidates the example. The POST /api/login failure example must show status 400 and { error: 'Missing password' }, not a successful token response.
CRUD coverage	Does the collection exercise Create (POST → 201), Read (GET list, GET single, GET 404), Update (PUT and/or PATCH → 200), and Delete (DELETE → 204)? Omitting Delete because 'nothing persists' misses the 204 no-content response, which is a distinct and commonly misasserted status code. Both PUT and PATCH are worth including because they have different semantics (full replacement vs. partial update).
Documentation clarity	Do request descriptions help a new team member without requiring them to open the API docs? 'Gets a user' is too vague. 'Retrieves a single user by numeric ID; returns 404 with an empty body if the ID does not exist on Reqres.in' is actionable. The inventory document should allow a reader to choose the right request without opening Postman.

Sample solution outline

›Folder 'Users': GET /api/users?page=2 → 200, body { data: [{id, email, first_name, last_name, avatar}×6], page, per_page, total, total_pages, support }; description: 'Returns page 2 of the user list; Reqres has 12 total users across 2 pages of 6 each'
›GET /api/users/2 → 200, { data: { id:2, email:'janet.weaver@reqres.in', first_name:'Janet', last_name:'Weaver', avatar: URL }, support: {url, text} }; GET /api/users/23 → 404, body {}; note: Reqres returns an empty object, not a { message: 'Not found' } shape
›POST /api/users { name:'QA Engineer', job:'API tester' } → 201, { name:'QA Engineer', job:'API tester', id:'971', createdAt:'2024-01-15T10:30:00.000Z' }; note: id is a string, not an integer — worth capturing in the example
›PUT /api/users/2 { name:'QA Lead', job:'Team lead' } → 200, { name, job, updatedAt }; PATCH /api/users/2 { job:'Senior QA' } → 200, { job, updatedAt }; DELETE /api/users/2 → 204, no body — save the example with 'No response body' noted in the description
›Folder 'Auth': POST /api/login { email:'eve.holt@reqres.in', password:'cityslicka' } → 200, { token:'QpwL5tpe83ilfWH2' }; POST /api/login { email:'peter@klaven.com' } → 400, { error:'Missing password' }
›Inventory excerpt: GET Users (list) | GET | /api/users?page=2 | 200 | Returns paginated user list; POST Create User | POST | /api/users | 201 | Creates a user, returns id and createdAt; DELETE User | DELETE | /api/users/2 | 204 | Deletes user; no response body

Common mistakes

Using the wrong HTTP method — POST creates (201), PUT/PATCH updates (200), DELETE removes (204); sending a DELETE request with Content-Type: application/json and a body, or using GET for creation, produces misleading test results
Not setting Content-Type: application/json on POST/PUT/PATCH requests — without the header some APIs ignore or misparse the body; add it explicitly even when Postman's raw JSON mode sets it automatically, so the intent is clear in the exported collection
Saving examples before verifying the status code — if GET /api/users/23 accidentally returns a cached 200 on first run, the saved example will show 200 instead of the correct 404; always check the status code in the response panel before clicking 'Save as Example'
Treating all successful responses as status 200 — POST to /api/users correctly returns 201 Created, and DELETE returns 204 No Content; asserting or expecting 200 on these is a misunderstanding of HTTP semantics that will cause false positives in test scripts later
Leaving requests named 'New Request' or 'Request 1' — request names are the primary navigation label in Postman's sidebar; names must describe the operation ('GET /users — single (found)', 'GET /users — single (not found)') so the collection is usable without opening every request
Creating a flat collection with no folders — a list of 10 requests without grouping is not a collection, it is a queue; folders by resource or domain (Users, Auth) are the minimum structure for a collection that others will use

Submission checklist

Postman collection exported as JSON (v2.1) with at least two folders
All CRUD operations covered: GET list, GET single, GET 404, POST, PUT or PATCH, DELETE
Content-Type: application/json set on all POST/PUT/PATCH requests
At least 6 saved examples covering the specified request/scenario combinations
Request descriptions added to all requests (1–2 sentences each, including expected status code)
Request inventory document: name, method, URL, expected status code, purpose note
Any discrepancy between expected and actual status codes documented

Extension ideas

+Add a 'Register' folder with POST /api/register (successful: { email:'eve.holt@reqres.in', password:'pistol' } → 200) and POST /api/register (missing password → 400); document how register differs from login in the request descriptions
+Use Postman's 'Visualize' feature to render the GET /api/users?page=2 response as an HTML table — this demonstrates that a collection can serve as a lightweight API explorer with formatted output, not just a request launcher
+Export the collection and import it into a fresh Postman workspace (or ask a colleague to import it); document any friction points they encounter — a collection that requires verbal explanation to use is not yet self-sufficient