What is API Testing?

What is API testing?

API testing means sending requests directly to an API and checking the response against what the specification promises: status code, headers, payload shape, authentication, error handling and response time. No browser or UI is involved. The test calls the endpoint the way another service or an SDK would, so it catches contract breaks before a consumer does.

How API testing works

A test is a request plus assertions. You pick an endpoint, set the method, headers, auth and body, send it, then assert on what comes back. Chain requests when one call depends on another (create an order, then fetch it by the returned id).

POST /orders
Authorization: Bearer <token>
{"sku": "A-100", "qty": 2}

assert status == 201
assert body.id is a string
assert body.qty == 2
assert response time < 300 ms

Run the same checks in a test runner on every pull request, and run a reduced set against the live API on a schedule.

What API tests cover

• Contract. Field names, types and required fields match the OpenAPI or GraphQL schema.
• Status codes. 2xx on success, the right 4xx for bad input (400, 401, 403, 404, 422), 5xx only for real server faults.
• Authentication and authorization. No token gives 401, another tenant's token gives 403, expired tokens are refused.
• Edge cases. Empty arrays, null fields, maximum lengths, malformed JSON, missing headers, oversized bodies.
• Rate limits. A 429 at the documented threshold, with a sensible Retry-After.
• Performance. Latency and error rate at the load you expect. See API performance metrics.

API testing vs UI testing

UI tests drive a browser through a flow and assert on what is visible. They are slow and break when the layout changes. API tests assert on responses directly, so they run in milliseconds and fail for one reason. Most teams keep the bulk of their checks at the API layer and a few UI tests for the journeys users actually walk. Both belong in the regression suite.

Types of API tests

• Functional and contract tests check correctness against the spec.
• Integration tests check that services work together, often against a stub from API mocking when a dependency is not available.
• Security tests probe auth, injection and excessive data exposure.
• Smoke tests hit a handful of critical endpoints after a deploy. See the smoke testing guide.
• Load tests check speed and errors under concurrent traffic. See load testing.
• Monitoring repeats checks on a schedule in production. See API monitoring.

Common mistakes

• Asserting only the status code. A 200 with the wrong body is still a failure.
• Testing only the happy path and skipping auth failures and bad input.
• Sharing mutable test data between tests, so order changes results.
• Hard-coding tokens and URLs instead of using variables per environment.
• Running performance checks from one machine next to the server, which hides network and regional effects.
• Never running checks against production, so a deploy that works in staging fails unseen.

Tools and where LoadFocus fits

Code-first runners (pytest with requests, supertest, REST-assured) suit regression suites. Postman and similar clients suit exploration. Spec-driven tools such as Schemathesis generate cases from an OpenAPI file.

• curl online sends a single request from LoadFocus servers and shows status, headers, body and a timing breakdown. It is a one-off check, and redirects are reported rather than followed.
• API status checker checks a public URL from 6 AWS regions at once. It is a snapshot, with no schedule, history or alerts.
• API monitoring runs checks on a schedule and asserts on status codes, response bodies, headers and response time, with alerts by email, Slack, Microsoft Teams and other channels. The free plan checks every 5 minutes; paid plans run more often.
• OpenAPI to k6 converts an OpenAPI or Swagger spec into a k6 script in your browser. You can run it on the load testing platform, which runs JMeter and k6 from 25 cloud regions.

The online API tester guide covers what browser-based testers can and cannot do.

FAQ: API testing

Is API testing the same as unit testing?

No. A unit test checks one function in isolation. An API test calls the running service over HTTP and checks the contract it exposes, so it also exercises routing, auth, serialization and often the database.

Do I need to know how to code to test APIs?

Not to start. A client like curl or a request builder is enough to send requests and read responses. Automating the checks in CI is where code or a configuration file comes in.

How often should API tests run?

Functional and contract checks on every pull request, a few critical checks after each deploy, and a scheduled subset in production so you hear about outages before users do.

What is the difference between API testing and API monitoring?

Testing runs before release to find defects. Monitoring repeats checks against the live API on a schedule and alerts you when something fails or slows down.

Which HTTP status code should a failed validation return?

Usually 400 or 422 for invalid input, 401 when authentication is missing, 403 when the caller is known but not allowed, and 404 when the resource does not exist. Pick one convention and test that the API follows it.