Beginner API testing

How to test REST APIs: a beginner's step-by-step guide

REST API testing checks whether an endpoint accepts the right request, returns the expected response, handles mistakes safely, and stays reliable as the application changes. This guide gives you a repeatable workflow you can use even if you are new to APIs.

Updated September 3, 202612 minute read

What you need before testing

Collect the endpoint URL, HTTP method, expected status code, required headers, authentication method, and an example request body. API documentation—often an OpenAPI or Swagger page—should provide most of this information.

EndpointThe resource URL, such as /users/42

MethodGET, POST, PUT, PATCH, or DELETE

HeadersContent type, authorization, version, and request identifiers

Expected resultStatus, response fields, values, and acceptable response time

Use a safe testing environment.

A create, update, or delete request can change real data. Start with a development or staging API and use test credentials rather than production secrets.

Step 1: define the expected behavior

Write down what should happen before sending the request. A useful test has a clear input and a clear expected result. For example: “When an authenticated user requests an existing profile, the API returns 200 and a JSON object containing that user's ID, name, and email.”

This prevents a common mistake: treating any response as correct simply because the server returned something.

Step 2: send a simple valid request

Begin with the smallest happy-path request. A read-only GET endpoint is ideal because it usually needs no body and does not modify data.

GET https://api.example.com/users/42
Accept: application/json
Authorization: Bearer <test-token>

Record the exact method, URL, query parameters, headers, and body. If a test fails later, this request record makes the result reproducible.

Step 3: check the HTTP status code

The status code is the first indication of the outcome. A successful read commonly returns 200 OK; a successful creation may return 201 Created; and a successful response with no body may return 204 No Content.

Do not check only whether the response is in the 2xx range. The exact code communicates meaning to clients. Our API status-code guide explains the common success and failure codes in more detail.

Step 4: validate the JSON response

Confirm that the body is valid JSON, contains the required fields, uses the documented data types, and returns sensible values. A response can have a successful status and still violate its contract.

{
  "id": 42,
  "name": "Asha Rao",
  "email": "asha@example.com",
  "active": true
}

id exists and is a number
name and email are strings
active is a boolean
No required field is missing or unexpectedly null
No private or undocumented field is exposed

Step 5: inspect important response headers

Headers describe how the response should be interpreted and handled. Check that JSON responses use an appropriate Content-Type, caching rules match the data, and request identifiers are returned when documented.

Content-Type

Usually application/json for a JSON response.

Cache-Control

Controls whether and how long a client or intermediary may cache the result.

Retry-After

May tell a client when to retry after a rate limit or temporary outage.

Request-ID

Helps support teams connect a public failure to internal logs.

Step 6: test invalid and missing input

Happy-path testing proves only that one valid request works. Now change one condition at a time: remove a required field, send the wrong type, use malformed JSON, request a missing resource, or provide an unsupported value.

The API should return a suitable 4xx status and a consistent, actionable error body. It should not expose stack traces, database details, or internal paths. See our REST API error-response guide for a secure error format.

Step 7: test authentication and permissions

Run separate tests with no credentials, invalid credentials, expired credentials, and valid credentials that lack permission. These cases should not all produce the same result.

401 Unauthorized

The caller is not authenticated with valid credentials.

403 Forbidden

The caller is authenticated but is not allowed to perform the action.

Verify that one user cannot read or modify another user's protected resource simply by changing an ID in the URL or body.

Step 8: check timing and reliability

Measure response time across several requests instead of relying on a single result. Note the median, slowest response, and behavior under realistic data sizes. The acceptable limit depends on the endpoint and the user experience it supports.

A fast error is not a successful test, and one fast success does not prove reliability. Evaluate status, body, and timing together.

Step 9: compare environments before release

Send the same request to your current API and the candidate version. Compare status codes, headers, JSON fields, data types, values, and response time. Investigate every unexplained difference.

Use the workflow in How to Compare Two API Responses to distinguish intentional changes from regressions.

Your first REST API test checklist

Use the documented method and endpoint
Test in a safe environment with test credentials
Define the expected result before sending
Verify the exact status code
Validate JSON fields, types, and values
Inspect important response headers
Test invalid input and missing resources
Test authentication and authorization separately
Measure response time across multiple requests
Compare old and new environments before release

Run your first comparison

Enter a baseline endpoint and a candidate endpoint, send the same request to both, and review the response differences in one place.

Open API Comparator