What is API Testing?

API testing is the practice of sending HTTP or gRPC requests to a service and verifying the responses match what the contract says they should. Unlike UI testing, API tests do not click buttons or render pages — they talk directly to the endpoints. The goal is to catch changes in behavior (a wrong status code, a missing field, a mis-sorted list) before those changes reach users.

There are five commonly named types. Functional testing checks that each endpoint returns the right response for valid and invalid inputs. Integration testing checks that a group of endpoints works together, including calls to downstream services and databases. Contract testing checks that the shape of responses matches a published specification (OpenAPI, Protobuf, GraphQL schema). Performance testing measures latency and throughput under load. Security testing checks authentication, authorization, and input validation against known attack patterns (OWASP API Top 10).

UI testing drives the browser or mobile app to reproduce user actions and assert on what they see. API testing skips the UI entirely and talks directly to the service. The trade-off: UI tests catch rendering bugs and user-journey regressions but are slow, flaky, and tightly coupled to specific HTML layouts. API tests are fast, stable, and independent of frontend changes but miss anything that only manifests in the browser. Most engineering teams use both — API tests for the bulk of regression coverage and a small number of UI tests for critical user flows.

The category splits into three generations. Manual scripting tools (Postman, Insomnia, REST Assured, pytest-requests) let you write individual requests and assertions by hand. Contract-testing tools (Pact, Spring Cloud Contract) validate that consumer and provider agree on response shapes. Traffic-capture tools (Keploy, WireMock record-playback, Hoverfly) record real API interactions and generate tests from them automatically. The three approaches are complementary — teams often use a traffic-capture tool for the regression layer and hand-written contract tests for new endpoints.

Keploy uses eBPF to capture HTTP, gRPC, WebSocket, and GraphQL traffic at the Linux kernel level — no SDK, no proxy, no code changes. Every captured interaction becomes a replayable test case with auto-generated mocks for all downstream dependencies (databases, queues, external APIs). Non-deterministic fields like timestamps and UUIDs are normalized automatically (see /noise-secret-management). The result is that a 15-minute capture session in staging produces a regression suite covering every endpoint exercised during capture, which typically reaches 90% API coverage without writing a single test script.

Run tests on every pull request, not just on main. Commit test fixtures alongside application code so every behavior change is visible in code review. Gate merges on test results via branch protection. Use deterministic replay to eliminate noise from timestamps and IDs (flaky tests erode trust in the suite and eventually get disabled). Alert to Slack or Discord on failures so regressions are noticed in minutes, not hours. For the full CI/CD recipe with exact workflow files for GitHub Actions, GitLab CI, and Jenkins, see /ci-cd-api-testing.

Aim for 90% coverage of the request paths users actually exercise — not 100% coverage of every documented endpoint. The distinction matters: many APIs have endpoints that are specified but never called in practice, and spending engineering time on tests for those endpoints is wasted effort. Traffic-capture tools make this trivial because they only generate tests for paths that traffic actually hits. For paths that do not get exercised during capture but are still important (error-handling branches, rarely-used admin endpoints), supplement with a small number of hand-written tests.

With a traditional tool like Postman or REST Assured, expect 1-2 weeks to write the first 50 tests for a medium-sized service and another 2-4 weeks to reach 90% coverage. With a traffic-capture tool like Keploy, the same service reaches 90% coverage in minutes after a 10-30 minute capture session. The bulk of the remaining time is spent reviewing the auto-generated assertions and adding domain-specific noise rules.