A browser-based API client wired to a realistic practice API. It has validation errors, auth, pagination and RFC 9457 problem responses. Send real requests, inspect status codes, headers and timing, and work through exercises that check your actual responses.
Response
Pick an endpoint on the right or type a URL, then press Send. Requests go from your browser directly to the URL.
JSONPath & schema practice
Extracting and validating values is half of API testing. These exercises run against the order payload from /api/mock/orders/1001 using the same JSONPath and JSON Schema engines used by common test tools.
Every endpoint lives under /api/mock on this site, so there are no keys to sign up for and no rate-limited third-party services. It behaves like a well-designed production API:
Validation returns 422 with field-level errors, duplicates return 409, malformed JSON returns 400, and the wrong media type returns 415.
Errors use application/problem+json (RFC 9457) with type, title, status and detail.
Auth: log in with tester / practice123 to get a bearer token for /auth/me.
Pagination includes X-Total-Count and RFC 8288 Link headers.
Utilities: /status/:code, /delay/:ms, a deliberately /flaky endpoint for retry logic, and /echo.
The API is stateless: create, update and delete requests are validated and answered realistically, but nothing is stored, so every learner always sees the same data. CORS is enabled, so you can also call it from Postman, cURL or your own Playwright tests.
Calling other APIs
You can enter any URL, but requests are sent by your browser, so the target must allow cross-origin requests (CORS). If it does not, the playground explains the failure instead of showing a fake response. That is a browser rule, and the same request will usually work from cURL or a test runner.
API testing FAQ
What is API testing?
API testing verifies an application through its programming interface instead of its user interface. For a REST API, a test sends an HTTP request, for example POST /users with a JSON body, and checks the status code, response body, headers and side effects. Good API tests also cover invalid input, missing authentication, permissions, pagination and error formats. On this playground, send GET /api/mock/products and inspect the response, then work through the exercises.
How do I practise API testing online?
Start in the request panel above. Send a GET, then a POST with a missing field and look at the 422 validation error, then log in to get a bearer token and call a protected endpoint. The exercises check your real responses, and the JSONPath and schema section trains response validation. Next, automate what you did: copy any request as cURL or as a Playwright APIRequestContext call from the Code tab, and try the graded cart API contract challenge.
What are the different HTTP request methods?
The common methods are GET (read a resource), POST (create a resource or trigger an action), PUT (replace a resource), PATCH (update part of a resource) and DELETE (remove it). HEAD returns only the headers of a GET, and OPTIONS describes what a resource supports, which browsers use for CORS preflight requests. GET, HEAD, OPTIONS, PUT and DELETE are idempotent: repeating them has the same effect as sending them once. The HTTP cheat sheet lists methods and status codes.
What is the difference between PUT and PATCH?
PUT replaces the whole resource with the body you send, so omitted fields are typically removed or reset. PATCH applies a partial update and changes only the fields you include. PUT is idempotent by definition; PATCH is not guaranteed to be, for example when it appends to a list. In tests, check that PUT without a required field is rejected and that PATCH leaves other fields unchanged. Try both on /api/mock/users/2, and read PUT vs PATCH and idempotency.
How do I validate a JSON API response?
Check it in layers: first the status code and Content-Type: application/json; then the structure, using a JSON Schema for required fields and types; then the business values, such as an order total equalling the sum of its items. Assert on specific fields rather than comparing whole bodies, so harmless changes like new fields or timestamps do not break tests. Try the API response validator or the JSON Schema validator with a response from this playground.
What are API assertions?
API assertions are the checks a test makes on a response. Typical ones: the status code is 201; the response time is under a threshold; a Location header is present; $.id is a number; $.email matches what you sent; an error response names the invalid field. Good assertions are specific enough to catch regressions but ignore volatile values such as generated IDs and timestamps. The API assertion builder writes them for Playwright, Postman, REST Assured or Cypress.
What is JSON Schema validation?
JSON Schema is a vocabulary for describing the shape of JSON: required properties, their types, formats such as email or date-time, allowed enum values, numeric ranges and array items. Schema validation checks a response against that contract, catching renamed fields, wrong types and missing data in a single assertion. Libraries such as Ajv for JavaScript and REST Assured's json-schema-validator for Java run it inside tests. Practise with the schema exercises above or the JSON Schema validator.
Can I test REST APIs without Postman?
Yes. You can use cURL from the command line, this browser-based playground, editor extensions such as REST Client for VS Code, or code: Playwright's request fixture, REST Assured in Java, or requests with pytest in Python. Code-based tests are the ones you will run in CI, so it pays to move beyond manual clients early. Generate starting points with the cURL generator and the cURL to code converter.
What are common API testing interview questions?
Expect: the difference between POST, PUT and PATCH; idempotency; which status codes to assert (200, 201, 204, 400, 401, 403, 404, 409, 422, 500); what to validate in a response; how to test OAuth 2.0 and JWT authentication; testing pagination and rate limiting; contract testing; and how you would run an API suite in CI. Worked answers are in the API testing interview questions, and the API testing checklist is a quick revision aid.
