Hi @Matt (pactflow.io / pact-js / pact-go) - thanks for sharing the link around schema != contract in the webinar, very helpful. Was hoping better understand how you would handle the following scenario • We are building a public facing API for customer consumption • We are design first, we build OAS, host it as documentation and build out endpoints based on the documentation • We want to know when our spec/documentation begins to stray from implementation Currently we run Prism as a validation proxy between our unit tests and API. Unit tests are simple, just checking responses match the status code / body we would expect. I think this aligns with the code-based schema testing in this article. Is there a better way to do this, maybe via Pact / Pactflow?

hello and no worries!

Correct!

What you have is really just a provider specification. We would argue contract testing in the broader sense involves two or more parties to agree on the contract, and in a first class way, including the test results. e.g. specification + proof = contract (In Pact, that’s a pact file/verification results pair, in BDCT that’s a pact file [consumer contract] and as OAS + test results [provider contract]) But this is a bit semantic, what matters is what’s a good fit for your use case. BDCT is good when your consumers can still give you a consumer contract, where that contract defines the list of endpoints and fields used by that consumer. The provider side contract is the OAS (+ test results to confirm correctness of that) is used to ensure it’s a super set of all consumer requirements. If you don’t know your consumers, you’re not going to get this info. You could get it from runtime traffic/inspection etc. but in reality, going to back to “good API practices” where you version the endpoint, don’t make backwards incompatible changes to the API and of course, test the API conforms to the spec, is the best advice we have. So, probably, PactFlow isn’t an ideal fit for this scenario