Hi all, question: we have a monilitihic API (documented in open api) that we use internally and is available to our customers. We don't have a microservices architecture and don't plan to. What advantages does bi-directional testing bring over say testing with Postman only?

bi-directional is a #CLS16AVEE feature (so best to ask specific Pactflow product features over there) I’m going to answer from the perspective of contract testing in general though. The short answer is that Postman doesn’t take into consideration what a consumer actually does with it, and so we can’t use that information to evolve the API safely in ways that traditionally are backwards incompatible. For instance, if we know all of the consumers of the API don’t use a particular endpoint, or even a particular header or field, we should be safe to remove them without resorting to cumbersome API versioning. You should still do functional testing (we can further discuss if postman is the best tool for that job), that is a necessary condition of a well tested API.

Hi Matt, Thanks for you answer! Gotcha. So using Pact (non bi-directional) isn't very useful for an API that has (in our case many) consumers that don't use Pact. In our situation the consumers of our API are our customers (we're a SaaS company). Will look into bi-directional contract testing and will move to #CLS16AVEE, we have an open api description for our API. Cheers

Pact is also very useful for the case where you publish client libraries