Modern applications typically communicate using a RESTful API service in order to keep your data in sync across multiple devices, share your content with other services, or receive updates. Sometimes these APIs are even implemented using multiple collaborating services, all communicating with each other over REST. These interactions have to be designed and documented so that each team knows what they must send and what they should expect to receive. Traditionally, this was done by the service provider writing a specification and publishing it for interested clients. Technologies such as OpenAPI (formerly Swagger) were developed around streamlining this process. However, this approach can often lead to "lowest common denominator" interfaces, or APIs that are overly generic and ill-suited for a particular application.
Consumer-driven contracts turn the development model on its head by allowing the client apps themselves to specify how the API should look and act on their side, putting the responsibility on the service provider to implement the functionality accordingly. By versioning these contracts, or "Pacts," we can also ensure that our APIs will remain backwards-compatible as they change. This is important as it prevents us from breaking the experience for users who haven't updated yet – reducing the amount of bug reports and complaints for the development team. These contracts also integrate into a continuous delivery pipeline to reduce the amount of manual testing required by a QA team.