Hey Team, I read that pact is not the tool for testing proxies. Now we are currently checking out if pact would work nicely to contract test our microservices and I think we have a special case here. Eager to know your opinion. We have 4 services. Let's call them Consumer, Proxy, MasterProvider and DetailProvider. Proxy is, as the name suggests, a proxy and simply forwards all calls to masterprovider. Proxy does not know (much) about the requests it forwards. But it knows a bit. E.g. it knows that there has to be an auth header, if present it will be checked, if not the request will be rejected. But more importantly, it knows about a query parameter "detail". If set to true the response of masterprovider will be parsed. Again we do not care about how this response looks in detail we are only looking for one defined attribute in the json that contains an ID which will then be used to invoke DetailProvider. The results of this call will be embedded in the original response of Master within a metadata section. Our problem here is: • How can our client be sure that the his request will be understood by Masterservice • But without Proxy having any more knowledge about requests that he already has The strange situation here is that proxy is not the owner of the api, but howere he does have logic. Is this an example about "what not to test with pact". How would you make sure (with or without pact) that client test fails when MasterProvider changes its API