What is API Testing?

What is API testing?

API testing is the practice of validating an HTTP, REST, GraphQL, or gRPC interface directly against its specification: contract shape, status codes, response payloads, authentication, authorization, error handling, rate limits, and performance under load. The tests skip the UI entirely and exercise the endpoint as another service would.

Because the API is usually the integration point between services (and the surface a public SDK builds against), API tests catch breaks that UI tests miss: schema drift, silent backward-incompatible changes, broken auth flows, and contract violations that don't fail until a downstream consumer parses the response.

API testing vs UI testing

Both validate the system; they live at different layers.

• UI testing drives a browser through a flow (login, search, checkout) and asserts on visible elements. Slow (seconds per assertion), flaky (network, animation timing, headless quirks), expensive to maintain.
• API testing sends HTTP requests directly and asserts on status, headers, body. Fast (tens of milliseconds per assertion), deterministic (no rendering surface), cheap to maintain. Covers contract + integration concerns the UI can't reach.

The pragmatic split: 80% of test coverage at the API layer, 20% at the UI layer for the few flows users actually see end-to-end. Inverting that ratio is the most common cause of slow, flaky CI pipelines.

What API tests cover

• Contract validation. Response schema matches the OpenAPI / GraphQL / protobuf spec. Field types, required fields, enum values. Catch breaks the moment they ship.
• Status codes. 2xx on success, correct 4xx on bad input (400 vs 401 vs 403 vs 404 vs 422), 5xx surfaces only on real server errors.
• Authentication and authorization. Unauthenticated requests return 401. Authenticated requests from the wrong tenant return 403. Tokens expire as advertised.
• Edge cases. Empty arrays, null fields, max-length strings, malformed JSON, missing required headers, oversized payloads.
• Idempotency. POST / PUT requests with an idempotency key applied twice produce a single side-effect.
• Rate limits and quotas. 429 returned at the documented threshold with correct Retry-After.
• Performance. p95 latency under SLO at expected load. See load testing for how to measure.

When to run API tests

1. On every PR. Part of the regression suite. Functional and contract checks run in seconds.
2. Post-deploy smoke. A handful of critical endpoint checks after every deploy to confirm the live API responds correctly. See smoke testing.
3. Performance regression. Run a load test against the API at expected peak before each release. Assert p95 + error rate didn't regress.
4. Pre-launch capacity sizing. Run capacity testing and spike testing against the API to know the ceiling before traffic arrives.

Key API testing tools

• Postman / Insomnia. Interactive request builders with collection-runner support. Good for exploration; collections can run in CI.
• REST-assured (Java), supertest (Node), pytest+requests (Python). Code-first API tests living next to the application code. The default for regression suites.
• Schemathesis, Dredd. Generate test cases automatically from an OpenAPI / GraphQL spec. Catch schema drift you didn't write tests for.
• JMeter and k6. Performance-side API testing. Both support HTTP, JSON / XML assertions, custom headers, auth flows. k6 has first-class GraphQL via JS; JMeter handles SOAP, JDBC, MQTT for non-REST APIs.

How to run API performance tests

A functional API test confirms the endpoint returns the right shape at low load. A performance API test confirms it still does so at production load. Both matter; the second catches the leak that brings the API down on launch day.

In k6, define your endpoint flow in JavaScript, add check() assertions on every response, and configure a ramping-vus scenario to expected peak. In JMeter, use an HTTP Request sampler with JSON Path / Response Assertions and a Thread Group sized to expected concurrency.

Run from LoadFocus for traffic from multiple cloud regions hitting the API simultaneously. Real API consumers are geo-distributed; single-origin load tests miss DNS, regional gateway, and edge-cache behaviour that production hits.

If you'd rather not write the scripts yourself, LoadFocus offers load testing services where engineers design API scenarios from your OpenAPI spec, run them at scale, and deliver an analysis with latency-by-endpoint and error-rate-by-endpoint breakdowns.