Currently, with the bi-directional workflow consumers must upload a contract in Pact format. Wheras the provider uploads an OAS. Is support for consumers uploading an OAS (instead of Pact contract) on your roadmap?

It’s not currently - mind describing your use case a bit more?

Let's say the consumer grabs a copy of the OAS schema as it was at at point in time (version 1) and commits it to their (consumer) codebase. Perhaps (before committing) they manually remove some parts of the schema that they're not using (e.g. endpoints). The consumer codebase uses that schema to programtically generate types, maybe API client etc. Either the full or filtered schema v1 is published as the consumer contract. We check with the broker, broker performs OAS compatibility check, consumer can deploy. A bit later, provider wants to make some changes. They do so in a way that would be breaking (with regards to OAS). Because consumer is deployed and using that contract, provider cannnot deploy. Provider revises their changes, makes them non-breaking (e.g. by versioning an endpoint). Provider deploys OK. Even later, consumer grabs v2 of the OAS and commits it to their repo (types, API client etc are regenerated). Consumer deploys. It might at this point be possible for the provider to finally remove some of the deprecated endpoints. ✂️✂️✂️✂️ TL;DR: • It can save the consumer having to write contract-by-example tests • It can possibly allow more exhaustive checking (e.g. possible enum values) It's 100% not using Pact / PactFlow to it's full potential. Kind of like using

openapi-diff

- however, we're still benefiting hugely from the broker's knowledge of what is deployed where

thanks, I understand the use case now

If you’re interested, we’ve been experimenting with a few ideas at PactFlow on improving contract testing. Think of it as a bit of a combination of Pact and BDCT, but hopefully better on both fronts

Keen to hear more about it!