Thanks @Yousaf Nabi (pactflow.io) just had a quick read through https://pactflow.io/blog/contract-testing-a-graphql-api/ and the example seems pretty close to the bespoke approach I implemented (which isn't surprising, as I took directions from @Matt (pactflow.io / pact-js / pact-go) on how to do that anyway!). The only thing I would point out (which is hard to capture in a standalone example) is that its really important that the GraphQL queries/mutations used to build the contracts should be referencing those that are actually used in the consumer code. As GraphQL is a massive multiplexing endpoint for endless variants of RESTful response shapes, its important the contract is always updated in lock step with what the consumer is actually using. I think the most interesting bit of GraphQL pact testing is actually keeping the provider in step with the myriad different contracts required by consumers - the flexibility the consumer has in choosing the "response shape" to a query or mutation can result in exponentially more contracts than with an equivalent set of REST APIs; we ended up with an approach which required effectively zero upkeep in GraphQL server code, as it relies on the ability of the more popular GraphQL server frameworks to introspect arbitrary schema-valid queries and build mock responses automatically (and of course anything not schema-valid gets a pretty immediate dusty answer). Without it, maintenance of provider verification tests would be a significant task.