API testing verifies that an API meets expectations for functionality, reliability, performance, and security. It tests the business logic layer between the presentation layer and the database layer.

What are the main HTTP methods used in REST APIs?

The five primary methods are GET (retrieve), POST (create), PUT (replace), PATCH (partial update), and DELETE (remove). HEAD and OPTIONS are also used for metadata and capability discovery.

What's the difference between a 400 and 500 status code?

400-series codes are client errors (bad request, unauthorized, not found). 500-series codes are server errors (internal server error, bad gateway, service unavailable). The distinction matters for debugging responsibility.

How do I test an API that requires authentication?

Common methods include Bearer tokens (OAuth2), API keys in headers, Basic Auth (username:password base64), and session cookies. Each requires passing credentials in the Authorization header or as parameters.

API Testing Guide: How to Test REST APIs Like a Pro

By RiseTop Tools · February 10, 2025 · 14 min read

API testing is the backbone of modern software quality assurance. Whether you're a QA engineer, a backend developer, or a DevOps practitioner, understanding how to systematically test REST APIs is essential for delivering reliable software. This guide covers everything from HTTP fundamentals to advanced testing strategies.

For hands-on testing, try our free online API tester — but first, let's build your knowledge foundation.

What is API Testing?

API testing sends requests to an API endpoint and verifies the response against expected results. Unlike UI testing, API testing directly validates the business logic layer — the server's processing, data manipulation, authentication, and business rules — without the overhead of a browser interface.

Why API Testing Matters

Speed: API tests run 10–100× faster than UI tests
Early detection: Catch bugs before the frontend is built
Coverage: Test edge cases that UI testing can't reach
CI/CD integration: Perfect for automated pipelines
Stability: Less flaky than UI tests (no rendering issues)

HTTP Methods: The REST Verbs

REST APIs use standard HTTP methods to perform CRUD operations on resources. Understanding each method's semantics, idempotency, and safety properties is fundamental.

Method	Operation	Idempotent	Safe	Has Body	Common Status
`GET`	Read a resource	Yes	Yes	No	200, 404
`POST`	Create a resource	No	No	Yes	201, 400, 409
`PUT`	Replace a resource	Yes	No	Yes	200, 204, 404
`PATCH`	Partial update	No*	No	Yes	200, 204
`DELETE`	Remove a resource	Yes	No	Optional	204, 404
`HEAD`	Get headers only	Yes	Yes	No	200
`OPTIONS`	Get allowed methods	Yes	Yes	No	200

*PATCH is idempotent only if the operation itself is idempotent (e.g., setting a field to a value). It's implementation-dependent.

💡 Key Concept — Idempotency: An operation is idempotent if calling it once has the same effect as calling it multiple times. PUT /users/42 with the same payload produces the same result whether you call it once or ten times. POST is not idempotent — ten POST requests create ten resources.

HTTP Status Codes Reference

Status codes are the API's primary communication mechanism. Testing the correct status code for each scenario is the first line of verification.

Code	Name	Meaning	When to Expect
1xx	Informational
100	Continue	Client should continue sending body	Large uploads with Expect header
2xx	Success
200	OK	Request succeeded	GET, PUT, PATCH, DELETE responses
201	Created	Resource created successfully	POST creating a new resource
204	No Content	Success, no body returned	DELETE or PUT with no response body
3xx	Redirection
301	Moved Permanently	Resource permanently relocated	API version migration
304	Not Modified	Cached version is still valid	Conditional GET with ETag/If-None-Match
4xx	Client Errors
400	Bad Request	Malformed request syntax	Invalid JSON, missing required fields
401	Unauthorized	Authentication required/failed	Missing or invalid token
403	Forbidden	Authenticated but not authorized	Insufficient permissions
404	Not Found	Resource doesn't exist	Invalid ID in URL path
409	Conflict	Request conflicts with state	Duplicate email on registration
422	Unprocessable Entity	Semantic validation errors	Valid JSON but invalid data (e.g., email format)
429	Too Many Requests	Rate limit exceeded	Exceeded API quota
5xx	Server Errors
500	Internal Server Error	Unhandled server exception	Bug in server code
502	Bad Gateway	Upstream server returned invalid response	Reverse proxy / load balancer issue
503	Service Unavailable	Server temporarily overloaded	Maintenance or capacity issue

Common API Test Scenarios

Professional API testing goes beyond happy paths. Here are the essential test categories every API test suite should cover:

1. Functional Testing

Verify that each endpoint returns the correct data, status code, and response format for valid inputs.

// Test: GET /api/users/1 returns correct user
GET /api/users/1
Expected: 200 OK
// Verify: response.id === 1, response.name is string, response.email matches email regex
  

2. Input Validation Testing

Test how the API handles invalid, missing, and malformed inputs.

Test Case	Input	Expected Status	Expected Behavior
Missing required field	POST /users with no name	400 or 422	Error message listing missing field
Invalid data type	age: "twenty"	400 or 422	Error about type mismatch
Out of range value	age: -5	400 or 422	Error about valid range
SQL injection attempt	name: "'; DROP TABLE--"	400	Input sanitized/rejected, DB safe
XSS attempt	name: "<script>alert(1)</script>"	200 (but sanitized)	Output escaped in response
Extremely long string	name: 10,000 chars	400 or 422	Rejected by length validation

3. Authentication & Authorization

Scenario	Expected Result
Request with no auth token	401 Unauthorized
Request with expired token	401 Unauthorized
Request with invalid token	401 Unauthorized
Valid token, insufficient permissions	403 Forbidden
Valid token, correct permissions	200 OK
Token from different user accessing another's resource	403 Forbidden

4. Error Response Format

A well-designed API returns consistent error responses. Test that errors follow a standard format:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "The 'email' field must be a valid email address.",
    "details": [
      {
        "field": "email",
        "message": "Invalid email format",
        "value": "not-an-email"
      }
    ]
  }
}
  

5. Pagination, Filtering, and Sorting

// Test pagination
GET /api/users?page=2&limit=10
// Verify: returns exactly 10 items, page metadata correct

// Test filtering
GET /api/users?role=admin&status=active
// Verify: all results match both filters

// Test sorting
GET /api/users?sort=created_at&order=desc
// Verify: results are in descending order by created_at
  

Authentication Methods

Method	Header Format	Security	Best For
Bearer Token (JWT)	Authorization: Bearer <token>	High	Most modern APIs
API Key	X-API-Key: <key>	Medium	Server-to-server, public APIs
Basic Auth	Authorization: Basic <base64>	Low	Internal tools, legacy systems
OAuth 2.0	Authorization: Bearer <token>	Very High	Third-party access delegation
HMAC	Custom signed header	Very High	Payment APIs (AWS, Stripe)

API Testing Best Practices

1. Test Response Time

Set performance thresholds for each endpoint. A well-designed API should respond within these guidelines:

Operation Type	Acceptable Latency	Target Latency
Simple CRUD (GET/POST)	< 500ms	< 200ms
Complex query/aggregation	< 2s	< 1s
File upload/download	Depends on size	Proportional
Batch operations	< 5s	< 3s

2. Use Meaningful Test Data

Never test with production data. Create dedicated test datasets that cover:

Normal cases (typical valid inputs)
Boundary cases (min/max values, empty strings, zero)
Edge cases (unicode characters, null values, extremely long inputs)
Negative cases (invalid types, conflicting states)

3. Verify Response Schema

Use JSON Schema validation to ensure responses match the documented contract. This catches breaking changes early.

4. Test Rate Limiting

Send requests exceeding the rate limit and verify:

429 status code is returned after the limit
Retry-After header is present
Requests succeed again after the cooldown period

💡 Pro Tip: Always test APIs in a dedicated test environment with isolated test data. Never run destructive tests (DELETE, POST with side effects) against production endpoints.

Setting Up a Test Request

# Example: cURL request with all common components
curl -X POST https://api.example.com/v1/users \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1..." \
  -H "Accept: application/json" \
  -H "X-Request-ID: 550e8400-e29b-41d4-a716-446655440000" \
  -d '{
    "name": "Jane Doe",
    "email": "jane@example.com",
    "role": "user"
  }'
  

🚀 Test Your APIs Now

Send requests, inspect responses, and debug APIs directly in your browser.

Open API Tester →

Conclusion

Effective API testing is a skill that combines HTTP knowledge, systematic thinking, and attention to detail. By covering functional tests, input validation, authentication, error handling, and performance, you build confidence in your API's reliability. Start with the scenarios outlined in this guide, automate what you can, and iterate as your API evolves.