How to Test API Endpoints: A Complete Guide

What Is API Testing and Why It Matters

API testing is the process of sending requests to an API endpoint and verifying that the response is correct. You check the status code, the response body, the headers, and the response time. You confirm that valid inputs produce expected outputs and that invalid inputs produce meaningful errors instead of crashes.

If you build or consume APIs -- and in 2026, nearly every developer does -- testing them is not optional. A broken API endpoint can take down a mobile app, corrupt user data, or silently return wrong results that propagate through your entire system. The cost of finding a bug in production is orders of magnitude higher than catching it during testing.

Consider a payment API that accepts a charge request. If you never test what happens when the amount is negative, or when the currency field is missing, or when the authentication token is expired, you are gambling that your users will never trigger those conditions. They will.

API testing is the fastest feedback loop a developer has. Unlike UI testing, which requires rendering a browser, clicking through forms, and waiting for animations, API testing sends a raw HTTP request and gets a raw response. A single curl command or a click in an API testing tool tells you instantly whether your endpoint works. No UI, no browser, no setup. Just a request and a response.

Types of API Testing

Not all API tests serve the same purpose. Understanding the different types helps you decide what to test and when.

Functional Testing

The most common type. You send a request and check whether the response matches what the API documentation promises. Does GET /users/1 return the user with ID 1? Does POST /orders create a new order and return a 201 status code? Does DELETE /sessions invalidate the session token? Functional testing answers these questions one endpoint at a time.

Validation Testing

Goes beyond "does it work" to "does it reject what it should reject." Send a request with a missing required field. Send a string where a number is expected. Send a body that exceeds the maximum allowed size. Validation testing ensures your API fails gracefully with clear error messages rather than crashing or accepting garbage data.

Security Testing

Tries to access endpoints without authentication, with expired tokens, or with tokens belonging to a different user. Tests for SQL injection in query parameters, checks whether sensitive data like passwords appears in responses, and verifies that rate limiting actually blocks excessive requests. Security testing is where you think like an attacker.

Performance Testing

Measures response times under normal load and under stress. How long does GET /search?q=term take with 10 concurrent users? With 1,000? At what point does the response time exceed your SLA? Performance testing reveals bottlenecks before your users hit them.

Integration Testing

Tests the full flow across multiple endpoints. Create a user, log in, create an order, fetch the order, cancel it, verify the user's order list is updated. Integration tests catch bugs that live in the seams between endpoints -- race conditions, state inconsistencies, and data that gets lost between services.

Manual vs Automated API Testing

Both approaches have their place. The key is knowing when each one makes sense.

Manual testing means sending individual requests using a tool like curl, a browser-based API tester, or Postman, and visually inspecting the responses. You are the test runner. You decide what to send, you read the response, and you judge whether it is correct.

Manual testing excels at:

• Exploratory testing -- poking at an unfamiliar API to understand how it works
• Debugging -- reproducing a specific bug with exact request parameters
• Prototyping -- testing a new endpoint during development before writing formal tests
• One-off checks -- verifying a fix in production or checking a third-party API's behavior

Automated testing means writing scripts or test suites that send requests, assert on the responses, and run without human intervention. Frameworks like Jest (JavaScript), pytest (Python), and RSpec (Ruby) can all make HTTP requests and validate responses programmatically.

Automated testing excels at:

• Regression testing -- catching when a code change breaks an existing endpoint
• CI/CD pipelines -- running hundreds of tests on every pull request
• Contract testing -- ensuring API responses match a schema on every deploy
• Load testing -- simulating thousands of concurrent requests

How to Test API Endpoints: Step-by-Step

This is a practical workflow for testing any REST API endpoint, whether you are building it yourself or integrating with a third-party service.

Step 1: Read the API Documentation

Before you send a single request, read the documentation. You need to know the base URL, the available endpoints, the HTTP methods each endpoint accepts, the required and optional parameters, the authentication method, and the expected response format. If the API has an OpenAPI/Swagger spec, open it in a viewer to see the full schema. Without documentation, you are testing blind.

Step 2: Set Up Authentication

Most APIs require authentication. The three most common methods are:

• API Key -- passed as a header (X-API-Key: your-key) or query parameter (?api_key=your-key)
• Bearer Token -- passed as an Authorization header (Authorization: Bearer your-token)
• OAuth 2.0 -- a multi-step flow that produces an access token, which is then used as a Bearer token

Get your credentials ready before testing. A 401 Unauthorized response is the most common first result when testing an API, and it almost always means the authentication is missing or formatted incorrectly.

Step 3: Send a Basic GET Request

Start with the simplest possible request. Pick a read-only endpoint -- usually a list endpoint like GET /users or a single-resource endpoint like GET /users/1 -- and send a request with proper authentication.

# Basic GET request with curl
curl -s https://api.example.com/users \
  -H "Authorization: Bearer YOUR_TOKEN" | jq '.'

Check three things: the status code is 200, the response body contains the expected data structure, and the Content-Type header is application/json. If all three pass, your authentication works and the API is reachable. You can now move on to more complex operations.

Step 4: Test CRUD Operations

Work through the full lifecycle of a resource. Create it, read it, update it, and delete it. This sequence tests the four fundamental operations and reveals state-related bugs.

# CREATE - POST a new resource
curl -s -X POST https://api.example.com/users \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice", "email": "alice@test.com"}' | jq '.'

# READ - GET the created resource (use the ID from the POST response)
curl -s https://api.example.com/users/42 \
  -H "Authorization: Bearer YOUR_TOKEN" | jq '.'

# UPDATE - PUT or PATCH the resource
curl -s -X PATCH https://api.example.com/users/42 \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice Smith"}' | jq '.'

# DELETE - Remove the resource
curl -s -X DELETE https://api.example.com/users/42 \
  -H "Authorization: Bearer YOUR_TOKEN" -w "\nHTTP Status: %{http_code}\n"

After each operation, verify the state is consistent. After POST, the GET should return the new resource. After PATCH, the GET should reflect the updated fields. After DELETE, a GET should return 404.

Step 5: Test Error Handling

This is where most developers stop testing -- and where most production bugs live. Deliberately send bad requests and verify the API responds with appropriate error codes and messages.

# Missing required field
curl -s -X POST https://api.example.com/users \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice"}' | jq '.'
# Expected: 400 or 422 with an error message about missing "email"

# Invalid data type
curl -s -X POST https://api.example.com/users \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": 12345, "email": "not-an-email"}' | jq '.'
# Expected: 400 or 422 with validation errors

# Non-existent resource
curl -s https://api.example.com/users/99999 \
  -H "Authorization: Bearer YOUR_TOKEN" -w "\nHTTP Status: %{http_code}\n"
# Expected: 404 Not Found

# No authentication
curl -s https://api.example.com/users -w "\nHTTP Status: %{http_code}\n"
# Expected: 401 Unauthorized

Step 6: Validate Response Structure

Beyond checking status codes, verify that the response body matches the expected schema. Are all documented fields present? Are the data types correct? Are dates in the expected format? Is pagination information included in list responses? Use a JSON formatter to make the response readable, then compare it field-by-field against the documentation.

Essential curl Commands for API Testing

curl is the universal tool for API testing. It is installed on virtually every operating system, and every API's documentation includes curl examples. Master these commands and you can test any API from your terminal.

GET Requests

# Simple GET
curl https://api.example.com/users

# GET with headers
curl -H "Accept: application/json" \
     -H "Authorization: Bearer TOKEN" \
     https://api.example.com/users

# GET with query parameters
curl "https://api.example.com/users?page=2&limit=10"

# GET with verbose output (shows request/response headers)
curl -v https://api.example.com/users

# GET showing only response headers
curl -I https://api.example.com/users

POST, PUT, PATCH, DELETE

# POST with JSON body
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice", "email": "alice@example.com"}'

# PUT (full update)
curl -X PUT https://api.example.com/users/1 \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice Smith", "email": "alice@example.com", "role": "admin"}'

# PATCH (partial update)
curl -X PATCH https://api.example.com/users/1 \
  -H "Content-Type: application/json" \
  -d '{"role": "admin"}'

# DELETE
curl -X DELETE https://api.example.com/users/1 \
  -H "Authorization: Bearer TOKEN"

Useful curl Flags

# -s  Silent mode (no progress bar)
# -S  Show errors even in silent mode
# -w  Custom output format (status code, timing, etc.)
# -o  Save response to a file
# -L  Follow redirects
# -k  Skip SSL verification (dev only!)

# Measure response time
curl -s -o /dev/null -w "Status: %{http_code}\nTime: %{time_total}s\nSize: %{size_download} bytes\n" \
  https://api.example.com/users

# Save response body and show status code
curl -s -w "\n%{http_code}" -o response.json \
  https://api.example.com/users

If you frequently convert curl commands to code for your application, the NexTool curl to Code converter translates curl syntax into Python, JavaScript, Go, PHP, and other languages instantly.

Parsing and Validating API Responses

Getting a 200 status code is necessary but not sufficient. You need to parse the response body and verify its contents.

Using jq for JSON Responses

jq is a command-line JSON processor that pairs perfectly with curl. Pipe your API response through jq to format, filter, and extract data.

# Pretty-print the full response
curl -s https://api.example.com/users | jq '.'

# Extract a specific field
curl -s https://api.example.com/users/1 | jq '.email'

# Get the first item from an array
curl -s https://api.example.com/users | jq '.[0]'

# Extract multiple fields
curl -s https://api.example.com/users | jq '.[] | {name, email}'

# Count items in the response
curl -s https://api.example.com/users | jq 'length'

# Filter by a condition
curl -s https://api.example.com/users | jq '[.[] | select(.active == true)]'

For more complex JSON inspection -- especially when dealing with deeply nested responses -- paste the output into the NexTool JSON Formatter for a collapsible tree view with syntax highlighting.

Checking Response Headers

Headers carry critical metadata that is easy to overlook. Pay attention to these:

• Content-Type -- should be application/json for JSON APIs
• X-RateLimit-Remaining -- how many requests you have left before being throttled
• Cache-Control -- whether the response is cacheable and for how long
• X-Request-Id -- a unique ID for tracing the request through server logs
• Link -- pagination URLs for the next and previous pages of results

# Show response headers only
curl -sI https://api.example.com/users \
  -H "Authorization: Bearer TOKEN"

# Show both request and response headers with the body
curl -sv https://api.example.com/users 2>&1 | head -30

Best Free API Testing Tools in 2026

Here are the tools that cover the full API testing workflow, from quick manual checks to full automation.

NexTool API Tester

A browser-based tool for sending HTTP requests and inspecting responses with zero setup. Select the HTTP method, paste your URL, add headers and a request body, and hit Send. The tool displays the status code, response headers, formatted response body, and response time. Everything runs in the browser -- your API keys and request data never touch a third-party server. Ideal for quick debugging and one-off tests.

Try NexTool API Tester

curl

Already installed on macOS, Linux, and Windows 10+. No downloads, no sign-ups, no GUI to learn. The syntax can be verbose, but it is universally understood. Every API's documentation includes curl examples, making it the lingua franca of API testing. Pipe the output through jq for readable JSON.

Postman

The most popular desktop API client. Its strength is collections -- saved groups of requests that you can share with your team, parameterize with variables, and run sequentially. The free tier covers most individual use cases. The downside is that it has grown into a heavy application with features most developers never use.

Bruno

An open-source alternative to Postman that stores collections as plain files in your project directory. This means your API tests live alongside your code and can be version-controlled with Git. No cloud sync, no accounts, no lock-in. Growing rapidly in 2026 among developers who prefer simplicity.

Common API Testing Mistakes to Avoid

After years of building and testing APIs, these are the mistakes we see developers make most often.

1. Only Testing the Happy Path

Sending valid data and getting a 200 response is the bare minimum. If you stop there, you have tested 10% of your API's behavior. The other 90% is error handling: what happens with missing fields, wrong data types, empty strings, SQL injection payloads, oversized payloads, concurrent requests to the same resource, and expired authentication tokens.

2. Ignoring Status Codes

Checking only the response body and ignoring the status code is a recipe for silent failures. An endpoint that returns user data with a 500 status code has a bug, even if the data looks correct. Always assert on the status code first, then the body.

3. Hardcoding Test Data

Tests that create a user with email: "test@test.com" will fail on the second run because the email already exists. Use unique identifiers (timestamps, UUIDs, or random strings) in test data. Clean up created resources after tests run, or use a fresh database for each test suite.

4. Not Testing Authentication Separately

When an authenticated request fails, you need to know whether the problem is authentication or the endpoint logic. Test authentication in isolation first: verify that a valid token returns 200, an expired token returns 401, and a token for a different user returns 403. Once authentication is verified, you can rule it out when debugging other endpoint failures.

5. Skipping Response Time Checks

An endpoint that returns correct data in 8 seconds is functionally correct but practically broken. Include response time assertions in your tests. A simple threshold like "this endpoint must respond in under 500ms" catches performance regressions before they reach production.

6. Testing Against Production

Sending POST, PUT, and DELETE requests to production APIs creates real data, modifies real records, and can trigger real charges. Always test against a staging or sandbox environment. If the API provides a sandbox mode (most payment APIs do), use it for all non-read-only testing.

Frequently Asked Questions

What is the easiest way to test an API endpoint?

The easiest way is to use a browser-based tool like NexTool API Tester. Paste the endpoint URL, select the HTTP method, add any headers or body data, and click Send. The response appears instantly with the status code, headers, and formatted body. For a quick GET request, you can even paste the URL directly into your browser address bar. For command-line users, curl is the fastest option: curl https://api.example.com/users sends a GET request and prints the response.

How do I test a POST API endpoint with JSON data?

Using curl: curl -X POST https://api.example.com/users -H "Content-Type: application/json" -d '{"name":"Alice","email":"alice@example.com"}'. The -X flag sets the method, -H adds the Content-Type header, and -d provides the JSON body. In a browser-based tool, select POST from the method dropdown, paste your URL, add the Content-Type header, enter your JSON body, and send. Use a JSON formatter to validate your request body before sending.

What HTTP status codes should I check when testing APIs?

The essential codes: 200 (OK for GET/PUT), 201 (Created for POST), 204 (No Content for DELETE), 400 (Bad Request -- invalid input), 401 (Unauthorized -- missing or bad credentials), 403 (Forbidden -- authenticated but not allowed), 404 (Not Found), 422 (Unprocessable Entity -- valid JSON but fails validation), and 500 (Internal Server Error -- a bug on the server side). Always test both success and error paths.

What is the difference between manual and automated API testing?

Manual testing means sending individual requests and inspecting the responses yourself. It is ideal for exploring APIs, debugging issues, and quick one-off checks. Automated testing uses scripts or test frameworks to run predefined test cases and assert on the results without human intervention. Automated tests run in CI/CD pipelines and catch regressions on every code change. Start with manual testing to learn the API, then automate the important paths.

Is it safe to test APIs in the browser?

Yes, if the tool sends requests directly from your browser to the API endpoint. Tools like NexTool API Tester run client-side, so your API keys and request data stay on your machine. Be cautious with tools that route requests through their own servers, as your credentials would pass through their infrastructure. You can verify this by monitoring the Network tab in your browser's developer tools.