How to Test REST APIs: A Step-by-Step Tutorial for 2026

Testing REST APIs is one of the most practical skills a developer can have in 2026. Whether you are building a frontend that consumes an API, developing backend services, or integrating third-party platforms, knowing how to send requests, inspect responses, and validate behavior will save you hours of guesswork.

This tutorial walks through the entire process from zero. No prior experience with API testing tools is required.

Step 1: Understand Your API

Before sending a single request, spend time understanding the API you are testing. This means reading the documentation and identifying key details:

• Base URL: The root address of the API (e.g., https://api.example.com/v1)
• Available endpoints: The specific paths you can call (e.g., /users, /orders/{id})
• HTTP methods: Which methods each endpoint supports (GET, POST, PUT, PATCH, DELETE)
• Request parameters: Query strings, path parameters, and request body schemas
• Authentication: How the API verifies your identity (API key, Bearer token, OAuth)
• Response format: What the API returns (usually JSON, sometimes XML)

If the API has an OpenAPI specification (formerly called Swagger), even better. You can import it directly into your API client and get all endpoints pre-configured.

Where to Find Documentation

• Public APIs: Check the developer portal (e.g., developers.stripe.com)
• Internal APIs: Ask your backend team for the OpenAPI spec or Postman collection
• No documentation?: Use the API client to explore endpoints and reverse-engineer the schema

Step 2: Set Up Your API Testing Tool

You need an API client -- a tool that lets you construct HTTP requests, send them, and inspect responses. For this tutorial, we will use RESTK, but the concepts apply to any modern API client.

1. Download and install RESTK from our download page
2. Create a new workspace for your project
3. Create a new collection to organize your requests (e.g., "User API Tests")

A collection is simply a folder that groups related requests together. As your test suite grows, this organization becomes essential.

Step 3: Make Your First GET Request

GET requests retrieve data without modifying anything on the server. They are the safest way to start testing.

1. Click New Request in your collection
2. Ensure the method dropdown says GET
3. Enter a URL. For practice, use a free public API:

https://jsonplaceholder.typicode.com/posts/1

4. Click Send

You should see a response like this:

{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\nsuscipit recusandae consequuntur..."
}

What to Check

• Status code: 200 OK means the request succeeded
• Response time: Displayed in milliseconds -- under 500ms is typically good
• Response body: The JSON data returned by the API
• Response headers: Metadata like Content-Type: application/json

Try a few more GET requests to get comfortable:

GET https://jsonplaceholder.typicode.com/posts          (list all posts)
GET https://jsonplaceholder.typicode.com/posts?userId=1  (filter by user)
GET https://jsonplaceholder.typicode.com/users           (list all users)

Step 4: Test POST, PUT, and DELETE Operations

POST -- Create a Resource

POST requests send data to the server to create something new.

1. Create a new request and set the method to POST
2. Enter the URL: https://jsonplaceholder.typicode.com/posts
3. Go to the Body tab and select JSON
4. Enter the request body:

{
  "title": "My Test Post",
  "body": "This is a test post created via API testing.",
  "userId": 1
}

5. Click Send

Expected response: 201 Created with the new resource including an id field.

PUT -- Update a Resource

PUT replaces an entire resource with new data.

1. Set the method to PUT
2. URL: https://jsonplaceholder.typicode.com/posts/1
3. Body:

{
  "id": 1,
  "title": "Updated Title",
  "body": "This post has been updated.",
  "userId": 1
}

Expected response: 200 OK with the updated resource.

DELETE -- Remove a Resource

1. Set the method to DELETE
2. URL: https://jsonplaceholder.typicode.com/posts/1
3. No body needed
4. Click Send

Expected response: 200 OK with an empty object {}.

Step 5: Work with Authentication

Most real-world APIs require authentication. Here are the most common methods and how to set them up:

API Key (Header)

Many APIs use a simple API key passed as a header:

GET https://api.example.com/data
Headers:
  X-API-Key: your-api-key-here

In RESTK, go to the Headers tab and add a new header with the key name and value.

Bearer Token

OAuth2 and JWT-based APIs typically use Bearer tokens:

GET https://api.example.com/me
Headers:
  Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

In RESTK, you can use the Auth tab, select "Bearer Token," and paste your token. The tool adds the Authorization header automatically.

API Key (Query Parameter)

Some APIs pass the key as a query parameter:

GET https://api.example.com/data?api_key=your-key-here

Add this in the Params tab rather than hard-coding it into the URL. This keeps things clean and makes it easy to swap values.

Step 6: Use Environment Variables

Hard-coding base URLs and tokens into every request is a mistake you will regret quickly. Use environment variables instead.

Create Environments

Set up at least two environments:

Development:

{
  "baseUrl": "http://localhost:3000/api",
  "authToken": "dev-token-12345"
}

Staging:

{
  "baseUrl": "https://staging-api.example.com",
  "authToken": "staging-token-67890"
}

Use Variables in Requests

Reference variables with double curly braces:

GET {{baseUrl}}/users
Authorization: Bearer {{authToken}}

Now switching from development to staging is a single click -- every request updates automatically.

Protect Sensitive Values

Store real tokens in the current value field (local to your machine) and use placeholder text in the initial value field (shared with your team). This prevents accidental exposure of credentials when sharing collections.

Step 7: Write Test Assertions

Manual inspection does not scale. Write test scripts that automatically verify your API behaves correctly.

In RESTK, add scripts in the Tests tab of any request:

Status Code Checks

nova.test("Returns 200 OK", function() {
  nova.expect(nova.response.status).toBe(200);
});

Response Body Validation

nova.test("Response contains expected fields", function() {
  const data = nova.response.json();
  nova.expect(data).toHaveProperty("id");
  nova.expect(data).toHaveProperty("name");
});

Response Time Checks

nova.test("Response time is under 500ms", function() {
  nova.expect(nova.response.responseTime).toBeLessThan(500);
});

Array Length Validation

nova.test("Returns at least 10 items", function() {
  const data = nova.response.json();
  nova.expect(Array.isArray(data)).toBe(true);
  nova.expect(data.length).toBeGreaterThan(9);
});

Header Checks

nova.test("Content-Type is JSON", function() {
  nova.expect(nova.response.headers.get("Content-Type")).toMatch(/application\/json/);
});

When you run the request, RESTK displays pass/fail results for each assertion alongside the response.

Step 8: Organize with Collections

As your test suite grows, organization becomes critical. Here is a recommended structure:

User API Tests/
  Auth/
    POST Login
    POST Register
    POST Refresh Token
  Users/
    GET List Users
    GET Get User by ID
    POST Create User
    PUT Update User
    DELETE Delete User
  Orders/
    GET List Orders
    POST Create Order
    PATCH Update Order Status

Tips for Collection Organization

• Group by resource, not by HTTP method
• Name requests clearly: "POST Create User" is better than "POST /users"
• Order requests logically: Auth first, then CRUD operations
• Add descriptions: Document what each request tests and what the expected behavior is
• Use folder-level scripts: Apply common setup (like authentication) to all requests in a folder

Step 9: Pre-Request Scripts for Dynamic Testing

Pre-request scripts run before a request is sent. They are useful for:

Generating Dynamic Data

// Generate a unique email for each test run
const timestamp = Date.now();
nova.variable.set("testEmail", `user_${timestamp}@test.com`);
nova.variable.set("testName", `Test User ${timestamp}`);

Then use {{testEmail}} and {{testName}} in your request body. Each run creates a unique user, preventing conflicts.

Chaining Requests

// In the "Create User" request's test script:
nova.test("Save user ID for next request", function() {
  const data = nova.response.json();
  nova.variable.set("userId", String(data.id));
});

Then in the "Get User" request:

GET {{baseUrl}}/users/{{userId}}

This chains the requests -- the second request uses data from the first.

Refreshing Expired Tokens

// Pre-request script that checks token expiry
const tokenExpiry = nova.variable.get("tokenExpiry");
if (!tokenExpiry || Date.now() > parseInt(tokenExpiry)) {
  // Token is expired -- the collection runner will
  // execute the refresh token request first
  nova.variable.set("needsRefresh", "true");
}

Step 10: Debugging Failed Requests

When a request does not return what you expect, work through this checklist:

Check the Basics

• Is the URL correct? Watch for typos, missing path segments, or wrong API versions.
• Is the method correct? A GET to a POST-only endpoint will return 405 Method Not Allowed.
• Is the body format correct? Sending form data when the API expects JSON is a common mistake.

Inspect the Response

• Read the error message. Many APIs return helpful error descriptions in the response body.
• Check the status code. Each code tells a story:

Use the Console

RESTK includes a console panel that shows the full request/response lifecycle:

• The exact URL after variable substitution
• All headers including those added by auth settings
• The raw request body as sent
• Redirect chains if the request was redirected
• TLS/SSL handshake details

This is invaluable when the request you think you are sending differs from what actually goes over the wire.

Compare with cURL

If you suspect the tool is modifying your request, export it as a cURL command and run it in your terminal. If the cURL request works but the tool does not, the issue is in the tool's configuration. If both fail, the issue is in your request structure.

Check CORS (for browser-based testing)

If you are testing from a web-based tool and getting opaque errors, CORS (Cross-Origin Resource Sharing) might be blocking the request. Native API clients like RESTK are not subject to CORS restrictions, which is one advantage of using a dedicated tool.

What to Test Next

Once you are comfortable with the basics, expand your testing practice:

• Error paths: What happens when you send invalid data? Missing fields? Wrong types?
• Edge cases: Empty strings, very long strings, special characters, null values
• Pagination: Does the API correctly paginate large result sets?
• Concurrency: What happens when you send multiple requests simultaneously?
• Idempotency: Can you safely retry PUT and DELETE requests?

Conclusion

Testing REST APIs is a skill that improves with practice. Start with simple GET requests to understand the API, move to write operations, add authentication, and gradually build up to automated test suites with assertions and dynamic data.

The most important habit is to test early and test often. Do not wait until integration time to discover that an endpoint behaves differently than you assumed.

Download RESTK to start testing your APIs with a fast, native tool that keeps your data local and your workflow smooth. You can also browse the complete feature list to see how RESTK supports every step of the API testing workflow.

---

Related reading:

• What is API Testing? The Complete Developer's Guide
• REST API Testing Best Practices: 10 Rules Every Developer Should Follow

Want to see these concepts in action? Check out our Getting Started with API Testing guide for additional examples and walkthroughs.