here Is anyone available to have a chat about a Consumer Pact being deployable when the implementation for a Provider endpoint hasn't been implemented?

Hello @Bernard Baker I am in for a chat 😉 When you wrote "Consumer Pact being deployable", strictly speaking, you do not deploy a Pact, right? You (only) deploy the "Consumer", correct? In a (nice) API-first approach, the Provider can indeed define/document an API endpoint (i.e. an interface) and even share it, before finishing (even starting) the implementation. Based on that definition/documentation, a Consumer could indeed start developing and testing, writing/generating a Pact file. Then, the critical part in your scenario is the Pact Verification. The Pact verification MUST (but you are asking for a SHOULD) done against the Provider implementation, that you don't have. Still, you could "analyze" the Pact and marked it as verified, but you CAN NOT change your mind afterward, once you say yes to a particular Pact file, you say yes forever! So, if you said "yes", then your implementation MUST follow the Pact file, that's the risk you have been taken by verifying without actually verifying. P.S. You can, of course, still change your mind, but then it MUST be the implementation of the "next version" of the API endpoint, you cannot change an existing version, even if the implementation was actually not "existing" 😁

Hi @Patrice Krakow thanks for getting back to me. That's right I only deploy the Consumer. In our API-first approach we would like the Consumer to be aware that an endpoint has not been implemented. We came to the resolution that the Provider's API should be verified by a tool like dredd before allowing a pact to be published.

In our setup, we have a way to address the question of the implementation of an API endpoint... In our (home-made) API Management solution, we make a radical distinction between the API endpoints, being solely the interfaces, and their implementations. The API (endpoints) definitions are captured within OpenAPI documents, the implementations are classic "pieces of software", and we have the explicit link between the two being the authorization to implement. Most of the API Management solutions have a workflow for the authorization to consume, usually called subscriptions, we have an additional similar mechanism for the authorization to implement. A service/component/piece-of-software MUST have the authorization to implement one or multiple API endpoints. This authorization to implement is materialized by a signed JSON Web Token which is sent at run-time to our "API Endpoint Discovery". In this manner, a running instance of a service/component/piece-of-software declares at run-time that it is implementing a particular set of API endpoints. That knowledge is used by the consumers who do not know in advance the physical address (internal DNS) of the service/component/piece-of-software implementing the API endpoint they want to call, but they query at run-time the "API Endpoint Discovery". In your scenario, our "API Endpoint Discovery" would also be able to answer the question: "Is there already a running instance implementing the API endpoint that is used by this (new) consumer I would like to deploy?" I don't know what kind of environment you have and if you could consider this kind of "architecture", but I would be happy to describe further what we have done and what we plan to do if it could help 😉