They answer different questions. A functional API test asks "does this service behave correctly?" A contract test asks "can this consumer and this provider still talk to each other?"

| | Functional API tests (e.g. Playwright request) | Consumer-driven contract tests (Pact) | | :--- | :--- | :--- | | What it checks | Business rules, data changes, error handling, authorization | That requests the consumer really sends get responses the consumer can handle | | What it runs against | A deployed service and its real dependencies | Consumer side: Pact's mock server. Provider side: the real provider, replaying the recorded requests | | Who writes it | Usually the team or SDET that owns the service | The consumer team writes it; the provider team verifies it | | When it fails | The service is wrong | One side changed in a way the other can't handle | | Speed | Slower: needs an environment and test data | Fast, and doesn't need both services deployed together |

Contract tests are not schema checks. Pact's docs point out that a contract is a set of concrete example interactions, which covers only what each consumer actually uses, while a schema describes everything the API could return. Contract tests also don't check business logic, so they complement functional tests rather than replacing them: use contracts to catch integration breaks early and cheaply, and keep functional tests for the behavior itself.

Sources: Pact docs, Pact FAQ, Playwright API testing