Assert the shape and meaning of the response (fields, types, headers, error bodies), and add consumer-driven contract tests. Pact's guidance is to treat consumer tests as unit tests for your API client and keep them as loose as possible while still preventing the provider from making breaking changes; the contract covers only the fields the consumer actually uses. Providers replay the contract against real code, and a Pact Broker with the can-i-deploy check tells you whether a version is safe to release. Schema testing against an OpenAPI spec is a provider-driven alternative. Keep a small number of integration tests for business logic that spans services.

In a consumer-driven contract, the consumer's tests record the requests they send and the responses they expect into a pact file, and the provider verifies itself against that file, so neither side needs the other running or a full environment.

Sources: Pact docs, Pact introduction