# Consumer-Driven Contracts

## Consumer-Driven Contracts

We'd like to introduce a strategy for keeping your applications \[communication layer, APIs, etc..] in sync.

> Read more about [Consumer-Driven Contracts](https://thoughtworks.github.io/pacto/patterns/cdc/).

The primary actors involved are the consumer and the service:

* *Consumer* — defines and publishes a contract using 

  [JSON Schema](http://json-schema.org/)
* *Service* — imports and satisfies a contract

## How it works

The *consumer* maintains the contract for a given *service*.

1. The *consumer* creates a contract for an endpoint in a given *service.*
2. The *consumer* [publishes](https://rivet.itg.sh/contracts/publishing) the contract to either an `npm registry` or git repository.
3. The *service* requires the contract, via `package.json`, at a very specific version, from the *consumer* from an npm package.
4. The *service* tests its API against the contract from the *consumer*.
5. If the contract tests fail, it means the contracts and the *consumer* application need to be updated to ensure that the *consumer* continues to work as expected.

![](https://1204129151-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LzJ3NVF7YKyFtX1MW7L%2F-LzJ3Nkz-YoYIT3ThTIi%2F-LzJ3ON6HAI-O9dhH-pJ%2Fconsumer-service.png?generation=1579810921282333\&alt=media)

### The client consumes the API

> Your client is a *consumer* app that defines the contract for its *service* app: The API server.

Changes to server *(or service)* responses can potentially break the client *(or consumer)* without API developers knowing about the breaking changes. To prevent this, the *consumer* publishes a contract that it expects the API to satisfy. When the *service* runs tests, it verifies that its responses will satisfy the *consumer’s* needs. If the responses don’t satisfy the *consumer's* needs, we know that the *consumer* won’t work as expected after the changes are published. This visibility aids in preventing us from deploying breaking changes.