:question: time A topic we love to hate, but we h...
# pactflow
y
time A topic we love to hate, but we have to use. 3rd Party API’s It is listed in our BDCT use cases https://docs.pactflow.io/docs/bi-directional-contract-testing/#use-cases For Consumer-driven Contract testing we’ve said the following and the reasons is expanded on here
Pact is not ideally suited to 3rd party APIs because 3rd parties are unlikely to validate your Pacts
For Bi-Directional Contract testing we said it can help
By pulling in the third party’s API specification (OAS) regularly, you can continually ensure your consumers are compatible
But we are light on examples! What common public API integrations would you like to see an example of? If you have an OpenAPI spec of a public API, feel free to share. If you want to get involved and showcase to a load of 👀 ’s and demo your own example, let your devo 🥑 set the stage for you. Even if you don’t have an answer to the above, but want to see some 🍖 on the 🦴 , then just drop us some kind of emoji. Drop us a reply in a 🧵
🙌 1
👋 1
m
I think the classic example is: 1. 3rd party publishes an OAS describing their API 2. On a regular schedule (or ideally, triggered by a notification from the provider that the OAS has changed) a provider side job uploads the provider contract to Pactflow. a. In this case, you would have to trust the provider tests their own API, so no actual verification work would need to be done 3. On the consumer side, it’s the same as other BDC examples (can use Pact or generate the examples from other tools/mocks)