Details
This ten-minute walkthrough explains how SmartBear Swagger uses PactFlow to test compatibility between API providers and their downstream consumers—not just whether an API conforms to a schema. Consumers publish their tested expectations as contracts, and providers verify against them independently, eliminating the need to run both applications in a shared test environment.
The video also shows how this approach can reduce reliance on complex end-to-end testing and how “Can I Deploy” turns compatibility results into a green-light or red-light release decision before changes reach production.
The walkthrough defines production readiness as more than confirming that an API matches its schema or provider-side requirements. An API must also remain compatible with the applications that consume it.
Traditional API development can overemphasize the provider: what the API team is building and whether the implementation meets its own specification. SmartBear Swagger contract testing brings downstream consumer expectations into the testing process, helping providers identify changes that would break an actual consumer requirement before deployment.
The expert distinguishes SmartBear Swagger’s approach from tools that use “contract testing” to describe a schema test alone. Schema testing is part of the solution, but the walkthrough explains that a complete contract test must also account for the consumer side of the integration.
This distinction matters because a provider can conform to a schema and still fail to meet a consumer’s expected requests, responses, or data structures. Swagger contract testing uses consumer-defined expectations to evaluate whether a specific provider version remains compatible.
Consumers use Pact to write unit tests that programmatically describe how they expect an API provider to behave. These expectations can include:
The response expected for a particular request
The response expected for another request type
The required structure of the returned data
The consumer runs these tests independently and publishes the resulting Pact file to PactFlow. The contract therefore represents the consumer’s tested expectations rather than an assumption made solely by the API provider.
Once consumers publish their contracts, providers retrieve those contracts from PactFlow and verify their implementation against the stated expectations.
The provider and consumer applications never need to run together or communicate directly during this workflow. This decouples their testing and development cycles, allowing each team to work at its own pace while PactFlow maintains compatibility information between particular provider versions, consumer versions, and environments.
The walkthrough acknowledges that end-to-end tests provide a high degree of confidence because they run components in an environment that closely resembles production. Their disadvantage is operational: as teams and systems scale, these tests become more complicated, expensive, and difficult to debug.
Pact was created to help teams find bugs earlier, deploy faster, and reduce their reliance on complex end-to-end environments. According to the expert, teams with long-term PactFlow experience commonly report spending substantially less time debugging end-to-end tests because they require fewer of them overall.
PactFlow does not provide only a general statement that an API and its consumers are compatible. It tracks particular versions of provider and consumer applications across particular environments.
In the demonstration, the application view indicates whether a Java API provider can be safely deployed with the latest versions of its consumers on the main branch. This version-aware view makes the compatibility result actionable within a deployment workflow.
“Can I Deploy” uses the compatibility information in PactFlow to return a practical green-light or red-light deployment result based on whether a change would break a consumer expectation.
The capability is available through:
The PactFlow user interface
A command-line interface
The SmartBear MCP server
This allows teams to place the compatibility decision directly into their deployment process instead of expecting someone to interpret multiple test results manually.
The expert connects contract testing to the pace of AI-driven development. As teams ship code faster, breaking changes can also reach deployment more quickly.
“Can I Deploy” provides a final compatibility check before release, helping prevent a provider from unintentionally shipping a change that breaks one of its API consumers.
Production readiness includes consumer compatibility
Practical implication: Test provider changes against downstream consumer expectations, not only provider requirements or schemas.
Schema testing is only part of a complete contract test
Practical implication: Do not treat schema conformance alone as proof that an API change is safe for every consumer.
Consumers publish expectations as Pact files
Practical implication: Capture expected requests, responses, and data structures in executable consumer tests.
PactFlow brokers the provider-consumer workflow
Practical implication: Consumer and provider teams can test independently without maintaining a shared integration environment.
Providers verify against published consumer contracts
Practical implication: Detect whether a provider change violates a known consumer expectation before deployment.
Compatibility is tied to versions and environments
Practical implication: Evaluate the exact provider and consumer versions intended for a specific release context.
Contract testing reduces reliance on complex end-to-end tests
Practical implication: Find integration problems earlier and spend less time debugging large end-to-end environments.
“Can I Deploy” returns a release decision
Practical implication: Add a green-light or red-light compatibility check to the deployment workflow.
AI-driven development accelerates change
Practical implication: Use automated compatibility gates to keep faster delivery from increasing unintended consumer breakage.
SmartBear Swagger contract testing verifies whether an API provider remains compatible with its consumers. Consumers define their expected requests, responses, and data structures in tests, publish the resulting contracts to PactFlow, and providers verify themselves against those expectations.
Schema testing checks whether API data conforms to a defined structure. The walkthrough explains that this is only one part of contract testing. Complete contract testing also incorporates the expectations of downstream consumers and checks whether a provider change would violate them.
A provider is the API being consumed. It retrieves published contracts from PactFlow and verifies its implementation against the expectations recorded by its consumers.
A consumer is an application that uses the provider API. It uses Pact tests to describe the requests it will send, the responses it expects, and the required structure of the returned data.
No. Consumers run their tests and publish contracts independently. Providers retrieve those contracts and verify against them separately. The two applications do not run together or interact directly during this process.
PactFlow stores information about API providers, consumers, and their contracts. It tracks whether particular provider and consumer versions are compatible in particular environments and acts as the broker between the two sides of the testing workflow.
The video does not claim that contract testing eliminates all end-to-end testing. It explains that contract testing can reduce reliance on complex end-to-end environments, help teams find bugs earlier, and decrease the time spent debugging end-to-end tests.
“Can I Deploy” evaluates PactFlow’s compatibility information and gives a green-light or red-light deployment result based on whether a release contains a breaking change for an API consumer.
The walkthrough states that “Can I Deploy” is available through the PactFlow user interface, as a command-line interface tool, and through the SmartBear MCP server.
According to the expert, AI-driven development has increased the speed at which teams ship code and, with it, the risk of deploying breaking changes. A compatibility gate helps prevent faster delivery from unintentionally breaking API consumers.
Great to great to be here with the team again. Hello everyone. How are things? My name is Joe, but you already know that. I'm on the solutions engineering team at SmartBear, but you already know that too.
I have spent time helping teams adopt our API design, testing and documentation tools. And Swagger is the is the main platform in that in that category. So I've worked with you know teams of QA teams, development teams, business analysts, platform engineering teams, all to roll out Swagger to improve their API design and documentation and governance.
The most unique solution that SmartBear has in this area in terms of making sure that your APIs are production ready is contract testing. So contract testing, PactFlow is the name of the tool that I am authenticating in order to use Drift. Drift is a part of our contract testing solution. So what am I looking at here? I'm looking at all of the APIs.
All of the API providers that I have in production and I'm also looking at all of the respective consumers of those APIs. And the application view here in PactFlow is telling me whether or not my APIs are compatible with the consumers that they have. Right. So here for example I have a a Java provider, which is a it's a Java API, and if I open up here, I can see that it is safe for me to deploy this version of the API with the latest version of its consumers on the main branch.
One of the things I want to do on today's session is just explain exactly what a contract test is, a Swagger contract test, and how that helps you to ensure that your APIs are are production ready. So a key part of what we consider production readiness and like application integrity more broadly in SmartBear and with Swagger is the ability for your consumers to competently integrate with your APIs. So API development is rarely one sided, although we typically in the past you kind of over index on the provider of the API, who's building the API, what are their requirements, and often the consumer or consumers of those APIs don't get as much of a look in when it comes to testing and and development of the API that they require. So contract testing has been around for quite some time as a methodology.
I wanted to give a crash course in contract testing because Swagger contract testing is it's something that really we we're the only solution that can do it in the way that we do it at this point in time, which is very exciting. So the the high level version of the story here is that in the past
If you were the provider of an API or APIs and you wanted to ensure that your API is going to work with all of its downstream consumers in production, you ran end-to-end tests, right? Pretty robust, complicated tests where you know this is a very simplified version of an end-to-end test, but you spin up a staging or a test environment, you deploy all of the relevant components that are going to be in production with your APIs, along with your APIs, and you run your tests through those.
those systems and you observe the results, right? End-to-end tests are great on the one hand because you get a very high degree of confidence from them because the environment you were testing in is extremely similar to the environment that you know or the production environment. The downside of end to end tests like this is that as your teams and your systems scale, end to end testing becomes more complicated and more expensive and harder to debug. So that was the problem that the team that created Pact had encountered
Originally. You know, they were trying to find a way to find bugs earlier, to deploy faster, and to reduce their reliance on complex end to end test environments. And Pact was the solution. If we zoom in on a you know, a specific example of an integration here, a provider is an API, and this might be the you know banking API that I was working on earlier in Swagger Studio. Who are my consumers, right?
Anyone who's consuming my provider API, they use Pact to write unit tests that basically programmatically store the requirements of the consumer of the provider in tests. Right. So the consumer is saying, you know, when I send such and such a request, I expect such and such a response. And if I send this type of a request, I expect that type of a response. And this is what the data should be structured like. Those tests run on the consumer side and they produce a contract, which is a Pact file, that gets stored in
PactFlow, which is part of Swagger contract testing, right? And that's the tool that we're looking at here is PactFlow, right? And it stores information about API consumers and API providers. Importantly, PactFlow tells you whether or not your consumers are compatible with your providers, particular versions of those applications and particular environments for those applications. And the way that PactFlow gets that data is through this workflow here. Your consumers run their tests and publish their contracts.
And then providers retrieve contracts from PactFlow and then verify themselves against what the consumer's expectations are. So at no stage in this workflow do the consumer and provider applications run in the same environment and interact directly with each other. And that's another ingredient of the you know Swagger contract testing secret sauce is that these two teams are now completely decoupled. They can run their tests and do their development at their own pace. And Swagger via PactFlow.
Is the broker between those two teams, right? Swagger will eventually tell them whether or not it's safe for them to deploy based on what Swagger knows about the consumer and about the provider. this is unique in the API testing market, right? You will hear a lot of vendors talk about contract testing.
When what they really mean is the schema test that I ran with Drift which is a part of a contract test, but it's only one part of the picture. Right. What most other vendors are missing is this consumer side of the equation. Now Swagger, through contract testing, can tell API providers about the requirements of their consumers, right? And it more most importantly, it can prevent the provider from deploying an API that breaks an expectation of a consumer.
So if you talk to teams that have been using PactFlow and contract testing for you know for a long time, what you typically will hear is that they have severely reduced the amount of time they spend debugging their you know their end-to-end tests because they've reduced their end-to-end tests generally. And they've also increased the velocity with which they can deploy APIs because of contract testing.
Can I Deploy in particular? Right, which you can see through the user interface here, Can I Deploy? It's also available as a command line interface tool. It's also available via our SmartBear MCP server. If you take one thing away from this about contract testing, make it make it Can I Deploy, right? Because Can I Deploy turns Swagger into a system that can basically green light or red light your deployments based on whether or not there's any breaking changes in them. The advent of AI driven development has severely increased the risk of breaking changes being deployed. That we're we're we're shipping code at breakneck pace. And Can I Deploy is you know it's it's it's the tool within the Swagger tool set for making sure that you don't end up shipping something that breaks one of your API consumers unintentionally. If that sounds interesting to anybody and they would like to spend a little bit more time talking to me or a member of the team that I work on about contract testing and make it specific to your own workflows and tech stack, just let us know. Right. I as you can see today, I'd be more than happy to talk at length about contract testing and how it can apply to your teams.
Scan that QR code for an easy way to get in touch with SmartBear and the Swagger team specifically to to ask any questions. If you're an existing SmartBear user or if you've used any of our tools before, you might have an account manager, you can reach out to them. And then you can also you know you can find me on LinkedIn. Joseph B. Joyce is my username, so if you want to get in touch there, by all means do. I I frequently post about all things API and Swagger and beyond.
Presenters:
Joseph Joyce
Senior Solutions Architect at SmartBear
Join Now for More Content & Events
For event and sponsorship inquiries, please email: [email protected]
