Practice Site · QA Lab
API Testing Playground.
Practise REST API testing in a safe playground built for QA engineers. Test users, products, orders, authentication, pagination, validation, status codes, schema checks and negative scenarios using tools like Postman, REST Assured, Playwright API, Cypress API and Karate.
Beginner to Intermediate30–90 minutesAPIAutomation friendlyAPIManualAutomation
Scenarios
18
Seeded bugs
9
Best for
API testing · Automation · Interview prep
Test data
✓ Included
Answer guide
✓ Included
On this page18 sections
// WHAT YOU'LL PRACTISE
- REST API request and response validation
- HTTP methods: GET, POST, PUT, PATCH, DELETE
- Status code checks
- Authentication and token handling
- Required field validation
- Schema validation
- Pagination testing
- Filtering and sorting
- Negative testing
- Authorization checks
- Error response consistency
- Idempotency and retry behaviour
// WHO THIS IS FOR
Manual testers learning API testingQA engineers practising PostmanAutomation testers building API test suitesSDETs using REST Assured, Playwright API, Cypress API or KarateInterview candidates preparing for API testing questions
// APP MODULES
AuthenticationUsersProductsOrdersCartPayments simulationError examplesAdmin-only endpoints
// ENDPOINT CATALOGUE
The endpoints to exercise — with expected status codes and the seeded bug hiding on each. Auth required where marked.
| Method | Endpoint | Purpose | Auth | Expected | Seeded bug |
|---|---|---|---|---|---|
| POST | /auth/login | Authenticate a user and return a token | — | 200, 400, 401 | No lockout after repeated failed logins |
| GET | /products | List products with pagination, filter and sort | — | 200, 400 | Pagination total count does not match returned records |
| GET | /products/:id | Fetch a single product | — | 200, 404 | — |
| POST | /users | Create a user | — | 201, 400, 409 | Required email field accepted as empty |
| GET | /orders | List the current user's orders | required | 200, 401 | Returns every order with no token (should be 401) |
| POST | /orders | Create an order | required | 201, 400, 401 | No idempotency — retrying creates a duplicate order |
| GET | /orders/:id | Fetch a single order | required | 200, 401, 403, 404 | A user can read another user's order (BOLA) |
| GET | /admin/users | Admin-only user listing | required | 200, 401, 403 | Normal users are not rejected (should be 403) |
// TEST DATA
Ready-to-use data for positive, negative and boundary scenarios.
Users
Valid userAdmin userLocked userDuplicate email
Tokens
Valid tokenExpired tokenNo token
Payloads
Valid productMissing required fieldInvalid idOversized page size
// PRACTICE MISSIONS
Small, focused tasks to warm up before the full lab.
30 mins
Write API tests for login
API testing, auth, schema validation
→ API test cases, Postman collection30 mins
Test order creation and idempotency
Negative testing, retry behaviour
→ Bug report on duplicate orders25 mins
Test authorization between two users
Object-level authorization (BOLA)
→ Security bug report// TEST SCENARIOS
Beginner
- Verify GET /products returns 200.
- Verify the product response contains the required fields.
- Verify GET /products/:id returns one product.
- Verify an invalid product ID returns 404.
- Verify POST /auth/login returns a token for valid credentials.
- Verify an invalid login returns 401.
Intermediate
- Verify product pagination works correctly.
- Verify filter and sort can be combined.
- Verify required fields are enforced when creating a user.
- Verify a duplicate email is rejected.
- Verify order creation requires authentication.
- Verify users can only access their own orders.
Advanced
- Verify expired-token behaviour.
- Verify the refresh-token flow.
- Verify retrying order creation does not create duplicates.
- Verify the response schema stays consistent across success and error responses.
- Verify the rate-limit response after repeated requests.
- Verify admin-only endpoints reject normal users.
// SEEDED BUGS
This app seeds 9 bugs. Try to find them first, then reveal the answer guide to check your findings — each row links to its Common Bugs category.
| Bug | Example | Skill | Common Bugs |
|---|---|---|---|
| Wrong status code | Validation error returns 200 instead of 400 | API correctness | API bugs → |
| Missing validation | Required email field is accepted as empty | Negative testing | API bugs → |
| Authorization bug | User can access another user's order | Security basics | Permission bugs → |
| Pagination mismatch | Total count does not match returned records | Data validation | API bugs → |
| Filter bug | Category filter returns products from other categories | Query testing | Search bugs → |
| Sorting bug | Price sort treats numbers as strings | Data logic | Data bugs → |
| Missing auth | GET /orders returns every order with no token (should be 401) | Auth testing | Authentication bugs → |
| Duplicate order bug | POST /orders has no idempotency — retrying creates a new order each time | Idempotency | API bugs → |
| Error format mismatch | 404s differ in shape — products use { error }, users use { message } | Contract testing | API bugs → |
GET /orders returns every order with no auth tokenSeverity: CriticalPriority: High
Steps to reproduce
- Send GET /orders with no Authorization header
- Observe the response status and body
Expected: 401 Unauthorized — no orders returned.
Actual: 200 OK with every user's orders in the body.
// REGRESSION CHECKLIST
The checks that would catch every seeded bug — reveal once you've done your own pass.
- Validation errors return 4xx, never 200
- Required fields are enforced on create
- A user can only access their own orders
- Pagination total matches the returned records
- POST /orders is idempotent on retry
- Error responses share one consistent shape
// MANUAL & AUTOMATION TASKS
Manual testing tasks
- Explore the API using Postman.
- Create positive and negative API test cases.
- Validate status codes and response bodies.
- Test required and optional fields.
- Test invalid IDs, invalid payloads and invalid tokens.
- Write bug reports for any mismatches.
Automation tasks
- Create a Postman collection with assertions.
- Create REST Assured tests for users and orders.
- Create Playwright API tests for login and order creation.
- Create Karate scenarios for schema validation.
- Add API tests to CI.
- Generate an HTML report.
// INTERVIEW MODE
Reflection questions to rehearse how you'd talk through testing this app.
How do you test an endpoint at the API level vs the UI level?
What does a good negative test suite for /auth/login look like?
How would you detect a broken object-level authorization bug?
How do you validate a response schema and a stable error contract?
What is idempotency and how would you test it on POST /orders?
// WHAT YOU'LL PRODUCE
API test casesBug reportsPostman collectionAutomation scripts
// SUGGESTED TOOLS
PostmanREST AssuredKaratePlaywright APICypress APINewmanOpenAPI / Swagger validatorJSON schema validator
// AUTOMATION STARTERS
Fork a ready-made framework to automate this app — each sample ships with setup, CI and reporting.
// DOWNLOADS
// PORTFOLIO WRITE-UP
Use this as a starting point for your CV, LinkedIn or portfolio — swap in the tools and findings that are actually yours.
I tested a REST API playground covering authentication, users, products and orders. I created positive and negative test cases, validated status codes and schemas, reported authorization and validation bugs, and automated key API flows using [tool name].
// NEXT RECOMMENDED APP
Domain workflow
Continue →Banking Practice App
Practise authentication, MFA simulation, account dashboards, transfers, payees, transactions, statements and session-timeout testing in a safe training app.