Real Application API Challenge Lab
Complete realistic workflows from the Playwright Automation Practice application. Every action sends a genuine backend request. Predict the response, inspect the network exchange, understand the HTTP behavior, and automate the same workflow with Playwright or Postman.
1. Register a New Account
Create a real account through POST /api/auth/register — this writes to the real users table.
Sample values are prefilled for quick practice. You can replace them with your own test data before sending.
A unique sample email is generated for convenience. You can edit it before sending.
Scenario Guide
Email will be omitted from this request.
2. Login
A registered visitor wants to log in. This sends a genuine POST /api/auth/login request and establishes the real httpOnly session cookie used across this entire site.
Not authenticated yet.
Shared demo credentials are prefilled for quick practice. You can replace them with your own test data before sending.
Password will be omitted from this request.
Scenario Guide
3. Browse Products
The API route can be working correctly while a specific requested product still does not exist. Compare a collection request, a successful item lookup, and a missing-resource lookup.
View products in Tech Shop ↗ The Tech Shop shows the customer-facing product catalog. Use the scenarios below to inspect the same catalog through the API.
A known existing product ID is prefilled for quick practice. You can replace it before sending.
This request asks for the product collection, not one specific product.
Scenario Guide
4. Shopping Cart
Practice authenticated cart requests and compare real 200, 400, 404, and 422 responses. Cart endpoints require a valid signed-in session.
Authentication required
Not signed in. Cart requests require a valid application session — the same real pw_session_token httpOnly cookie used across this site. Sign in once to create that real session.
Authenticated
Scenario Guide
5. Checkout / Create Order
Checkout creates an order from your authenticated, server-side cart. It requires a signed-in session, a non-empty cart, and a valid payment card. Card details are fetched live from the real /api/payment-cards.json endpoint — nothing here is guessed.
Authentication required
Not signed in. Checkout requires the same real pw_session_token session used across this site.
Authenticated
Card IDs come from the real /api/payment-cards.json endpoint used by the Tech Shop checkout.
Scenario Guide
Complete a successful checkout above to unlock the API Workbench below.
✓ Order created successfully.
You can now retrieve this order using the APIs below to understand how different HTTP status codes behave.
Execute
Retrieve My Order
GET /api/order-details.json?id=<createdOrderId>
Expected: 200 OK
Retrieve the order that was just created.
Retrieve Another User's Order
GET /api/order-details.json?id=<otherUsersOrder>
Expected: 403 Forbidden
Authenticated correctly but requesting another user's order.
Retrieve Archived Resource
GET /api/http-lab/orders/PW-0001/archived
Expected: 410 Gone
Resource intentionally removed permanently.
Complete a successful checkout first.
Execute a request on the left to see its response here.
Execute a request on the left to see why it behaves the way it does.
Execute a request on the left to see it here in Postman format.
Execute a request on the left to see its real OpenAPI/Swagger documentation here.
401 — "Who are you?"
The server does not recognize you as authenticated at all.
403 — "I know who you are, but you can't do this."
You're authenticated — your role just doesn't permit this action.
Where did you already see these?
Retrieve My Order — 200 OK
Authenticated correctly and accessing your own resource.
Retrieve Another User's Order — 403 Forbidden
Authenticated correctly but requesting another user's resource. This is authorization, not authentication.
Successful Checkout — 201 Created
Authenticated request successfully created a new resource.
Archived Resource — 410 Gone
This is not an authentication or authorization error — it demonstrates resource lifecycle semantics: the resource existed previously, but has been permanently removed.
6. Rate Limits & Temporary Failures
Production Infrastructure Behaviour Simulator
In the previous section you interacted with a real checkout workflow against the real application backend. Real production systems also depend on external services — inventory providers, payment gateways, shipping providers, and rate-limiting infrastructure.
A local training application cannot naturally overload these services or make them randomly fail. This section therefore provides deterministic production behaviour simulators: isolated lab endpoints whose HTTP status codes, headers, and retry behaviour accurately reproduce what automation engineers encounter in production. You are not crashing anything real — you are reproducing production behaviour in a controlled, repeatable way.
Production Failure Scenarios
Select a scenario on the left, then send the request — the result appears here.
7. Production Portal Investigation
A production deployment has just completed. QA reports that some navigation destinations may be healthy, redirected, removed, missing, or temporarily failing.
You are the automation engineer responsible for investigating this portal. You do not know which links are broken yet.
What you might find
Healthy Page
Expected: 200
Redirect
Expected: 302
Access Restricted
Expected: 403
Missing Resource
Expected: 404
Archived Resource
Expected: 410
Server Error
Expected: 5xx
Portal Directory
Selected Portal
None · Not Checked
Investigate a portal destination on the left — the classification appears here.
2xx Success
3xx Redirect
4xx Client Errors
5xx Server Errors
Select any HTTP status code above to view its meaning, common causes, automation guidance, and example response.
Category
Meaning
Typical Causes
Real-world Examples
Automation Validation
Common Confusion
Raw Example Response