 So I'm going to take five key practices for you to be able to do contract driven development API design first The key idea is you know you want to collaboratively design the API and Document the API using one of the standard specifications so that you have it available and referenced by Everybody else once you have that then treat it like code Right don't treat it like some documents that you pass around over email treat it as code and put it in a central like git repo Once you have it in central git repo, then you can do several interesting things on it right like compatibility testing quality testing once you have that then as a provider of a service you could now start taking those Specification as executable specification the the open API contract or this deal or Async API whatever you have you can actually convert it into a contract without writing a single line of code And that's kind of what I'm going to show you today And then as a consumer of a particular service, I'd also be able to take that as a stub and Disconnect with the other things the big idea here is you're all working off the same Central repo which means you're not going to be disconnected in terms of the providers move forward with some other Implementation, but you are behind generally that's the challenge So this is why you need to put it in central repo You need to run this as a contract test in their pipeline as a provider's pipeline as any time You basically try to build you have to first make sure you are still in line with the contract that you agreed with and all Of this is automated So there's no manual stuff and then finally you know as a consumer I can work off the same contract that's the five practices in contract driven development