With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

Hyrum Wright

If you've worked with APIs long enough, you've lived this. You changed something that wasn't in the contract — an optional field that appeared when it usually didn't, an undocumented header quietly removed — and somewhere, silently, a consumer broke. Not because you violated the spec. Because they'd built on the gap between the spec and reality.

This is the thing schemas have never been able to protect you from.

Schemas are not contracts.

A schema tells you the shape of your data. It validates structure at a point in time. What it cannot do is verify that your running service continuously honours its own spec as the codebase evolves, or give you any visibility into what your consumers are silently depending on.

Put another way: your provider contract is not your API. It's a map — it's not the terrain.

Contract testing shines a light in the darkness of the gaps between specification and real-world usage. But to understand why, we need to look at exactly where those gaps appear, and why they're harder to close than they might seem.

A gap with two sides

The gap between schema validation and contract testing isn't just a tooling inconvenience, it's a fundamental problem with two distinct faces.

On the provider side, there are actually two classes of problem.

The first is straightforward: your API drifts from its spec, even with the best intentions. Teams that generate specs from code can end up with incorrect definitions if annotations fall out of date, a genuine issue we've heard from customers, including a large security organisation who discovered their generated spec no longer matched their implementation. Sometimes there are gaps in spec generators that require manual configuration or intervention. Sometimes there are simply bugs in the wiring between code layers that only surface during testing. In every case, your schema still passes. Your tests are green. But your spec is now a fiction.

The second class of problem is subtler and harder to solve: certain API behaviours simply can't be fully expressed in a schema. Polymorphic payloads ( anyOf, oneOf, and the like) are a good example. Under which conditions can a consumer expect a particular shape in the response? OpenAPI doesn't specify the preconditions for these behaviours. Nor does it fully capture the semantics of optional fields, enum values in context, or ordering guarantees. The map has edges. Beyond them, there be dragons.

On the consumer side, your consumers are navigating that incomplete map and making assumptions about how it can be used. They build on undocumented behaviours. They treat optional fields, or polymorphic variants, as if they're guaranteed under certain conditions. They rely on ordering you never promised. Hyrum's Law in practice: the observable behaviour of your system becomes the real contract, whether you intended it or not.

This is exactly why we've long argued that specification testing and consumer contracts are both necessary and complementary. Specification testing gives providers confidence that their docs are a reliable, accurate map of the API. Consumer contracts illuminate the subtle behaviours the map can't express: the real, observed usage patterns that no schema alone will ever capture.

And here's where it gets practical: teams aren't just doing schema validation, they're already doing functional API testing too. The challenge is that they don't see why they should also adopt contract testing on top of what they're already doing. More tools. More workflows. More effort. Our answer to that is simple: you shouldn't have to choose. Done right, spec-driven testing and contract testing shouldn't be parallel tracks. They should be one workflow. We'll come back to that.

Building the bridge with bi-directional contract testing

Consumer-driven contract testing — the idea that consumers should define and publish their expectations — has been an answer to the consumer-side problem for over a decade. Pact pioneered the principles of making consumer behaviour explicit, verifiable, and visible to the providers who need to honour it.

But adoption by some teams was slow, not because of the idea, but because of the cost. Teams had already invested in OpenAPI. They had schemas, documentation, existing test suites. Starting over with a new paradigm wasn't always viable.

Bi-Directional Contract Testing (BDCT) was the bridge. It let teams use their existing OpenAPI specs and existing test tools as the foundation for provider verification, dramatically lowering the barrier to entry. Teams using BDCT report more than 50% reduction in the time needed to create contract tests, and over 40% of our customers have now adopted it.

But one gap remained. BDCT could tell you whether your spec was compatible with consumer expectations. It couldn't verify that your running service actually matched the spec it was being compared against. The provider side still had no enforcer and finding one wasn't easy.

Teams had to source their own solutions. Some already had tools in place. Others asked us what we recommended. For years, Dredd was the go-to open source answer, but it's now officially archived and no longer maintained, leaving a real gap in the ecosystem. Alternatives all came with trade-offs: Postman requires custom schema validation scripts added to each and every request ( pm.response.to.have.jsonSchema(...) ), introducing manual effort and additional maintenance. Language-specific tools like RestAssured work well within a single team's stack but fracture as organisations grow. What teams actually need is a single solution they can adopt, educate around, and scale consistently across teams and technologies.

Introducing Drift

Today, we're excited to introduce Drift — spec-driven API testing for the provider side.

Drift runs deterministic, automated checks to verify whether your API implementation actually conforms to its OpenAPI definition.

Here's what that looks like in practice:

• Spec-driven: your OpenAPI definition is the source of truth — and all schema tests are derived directly from it
• Plug-and-play CLI: download and run in seconds, locally or in any CI pipeline
• Declarative and version-controlled: deterministic test suites that live alongside your code, not in a separate tool
• Extensible: customise behaviour using scripting, or extend capabilities through the plugin architecture
• AI-powered: automatically generate a full test suite from your spec in minutes, and use AI to maintain and fix tests as your API evolves

Used standalone, Drift is a fast, lightweight way to catch provider drift before it reaches your consumers.

Used alongside PactFlow's BDCT workflow, it becomes something more powerful. Drift enforces the provider spec against real, running behaviour. PactFlow surfaces what consumers actually depend on. And PactFlow's can-i-deploy capability gates your deployments, ensuring that no change goes out that would break a known consumer. All at enterprise scale.

Together, both sides of the contract are held to account simultaneously, unifying spec-validation an contract testing into a single workflow, allowing teams to evolve both provider and consumer systems safely over time, with confidence.

Why this matters more than ever

The agentic AI era isn't on the horizon. It's here.

AI systems are generating APIs, writing specs, and consuming endpoints as autonomous tools at machine speed, with no human in the loop to notice when something quietly diverges. An LLM can produce a complete OpenAPI document in seconds. But without enforcement, that spec is just text. A statement of intent with no mechanism to verify it.

In a human-paced development cycle, drift gets caught in a code review or a QA cycle. In a machine-paced cycle, it gets caught in production by a customer, or by an AI agent behaving in ways nobody anticipated.

The volume and velocity of API creation now demands quality tooling that is automated, continuous, and grounded in the spec you already have. This is what SmartBear means by Application Integrity — in the AI era, software must demonstrably do what it says. Not just document it. Prove it, automatically, at every stage of the lifecycle.

Drift is that evidence layer at the API boundary.

Schemas can be contracts

Schemas cannot become contracts in and of themselves. But we now have the tooling to make them a meaningful part of a contract testing solution.

A contract requires two things: a shared agreement, and a mechanism to enforce it from both sides. PactFlow combined with Drift ensures the map matches the terrain.

For the first time, the full picture is available in one workflow. Design your API. Verify it conforms. Know what your consumers depend on. Deploy with confidence.

Drift is the keystone of a new standard for API integrity built for the agentic API lifecycle, where APIs are created faster, consumed by machines, and trusted at a scale that demands more than documentation. Whatever the technology, whatever the protocol, PactFlow and Drift will be there to ensure every API is high quality, trustworthy, and safe to release.

Drift is available now, to all PactFlow and Swagger Contract Testing customers.

Try Drift today →

Hello and welcome to Part 3 of our PactFlow AI-Automation Blog Series.

In Part 1, we explored the challenges of contract testing and its limitations. Part 2 made the case for generative AI and examined current solutions like GitHub’s CoPilot.

Now, in this final installment, I'm excited to present our vision for the future of AI-augmented contract testing and to officially launch our open beta.

We left off discussing some of the challenges and limitations of existing AI solutions built by some of the largest and most well-funded companies on Earth. So, a logical question to ask is: why us?

Why Us?

Great question. To answer it, we need to first explain our perspective on AI—how we see it affecting our customers, the software industry, and how we plan to integrate it into PactFlow. While you can find a high-level overview on our AI page, let us dive a little deeper into our position.

Our Position on AI

At SmartBear, we see AI as transformative—not just for our customers, but for the software industry. Generative AI tools like ChatGPT and CoPilot have demonstrated the potential to dramatically enhance efficiency, accelerate learning, and offer valuable insights that were previously difficult to uncover.

But there is one core principle we hold onto: Our approach to AI is a human-centered one - it will augment and empower our developers, testers, and engineers, giving them the freedom and time to focus on the complex, creative, and rewarding tasks that deserve their ingenuity.

We expect the most innovative solutions to complex problems in software development intersect at the intelligent use of modern technologies, and the creativity and beauty of human craftsmanship.

As discussed in part 2, we believe in the benefits of test-driven development (TDD) and the strains it places on software design and quality. This can be in tension with some of the capabilities of AI to rapidly produce working software.

For example, no AI tool today can fully comprehend the complexities of a production incident at 3 a.m., much less communicate with stakeholders and customers. This is important because the quality (e.g., readability) of software being debugged at 3 a.m. matters.

Our AI should, therefore, also support human decision-making, not replace it.

Lastly, there is nothing more important than our customers' trust. We take this responsibility seriously when it comes to AI, including being proactive about AI ethics and embedding responsible practices in every phase of our product lifecycle.

What About PactFlow?

The future of large language models (LLMs) and AI innovation is clear: they will continue to get more powerful, faster, and cost-effective. But here’s where our unique expertise shines—these tools will still rely on foundational knowledge, whether it’s understanding HTTP clients like curl, working with specifications like OpenAPI, or using libraries like Pact.

PactFlow is at the epicenter of the contract testing industry. Our team has been shaping the contract testing ecosystem for years, and we’re continuing to guide its evolution. Our fingerprints are already visible in today's generation of AI platforms (as an example, I've noticed how OpenAI and Anthropic generally choose to use chai assertions and mocha when creating Pact JS tests, and this is unlikely to be a coincidence if you look at my GitHub activity).

So, we'll continue to bet on the future of Pact and contract testing - just as we've always done.

But this still doesn't answer why we should build an AI-based solution. The answer lies in what our customers want from us. Our customers simply want to make API integration testing as easy, reliable, cheap, and fun as it can be.

The simplest answer, then, is that AI is only a means to an end – that end being a delightful product experience.

Our product experience must encompass more than just creating or updating contract tests - it should make it easy to create better and more precise contract tests, to identify gaps in test coverage, to help debug failures, to use the latest APIs and libraries, to gain insight into the system, and much more.

PactFlow is the global leader in contract testing - who is better positioned to guide AI to contract testing nirvana?

Introducing PactFlow’s AI-Augmented Contract Testing 🚀

Today, I'm thrilled to announce the launch of our AI-augmented contract testing solution, now available in open beta.

Our latest test generation capability featuring HaloAI uses generative AI to help users quickly generate Pact tests. By leveraging data from source code, OpenAPI descriptions, or HTTP traffic captures, it dramatically reduces the time and effort involved in creating and maintaining contract tests.

For a demonstration, check out a walkthrough of the key features here:

Next Steps?

PactFlow’s AI-augmented contract testing is available across all plans during the beta phase starting today. If you’re ready to try it out, head over to our documentation to get started.

This is just the beginning – stay tuned as we continue to invest in this new direction.

Hello and welcome to part 2 of our PactFlow AI Testing Blog Series.

In our last blog “The Case for Contract Testing: Cutting Through API Integration Complexity“, we looked at how isolated testing leads to redundancy. We also explored the testing pyramid, highlighted overlapping concerns, and explained how leveraging contract testing (CT) in your testing arsenal enables graceful system evolution.

To read more about the traditional pain points of contract testing, you can recap by reading part 1 of this blog series.

With the rise of Generative AI, organizations and practitioners have been wondering how best to harness these emerging technologies to alleviate common problems across many workflows, with contract testing not an exception.

The differences between a good contract testing implementation and a bad one are stark. Whilst the utopia is being able to make changes with confidence and being able to sleep soundly, whilst on-call, as you know the phone won’t be ringing because of one of your endpoints, contract testing hell can feel like you wish you never started, and will invariably have the bean-counters at your door, asking about why that ROI never came to fruition. Read Alejandro Pena’s guide to understanding the ROI of Contract testing here

The potential of AI in Contract Testing

So, one may be wondering what potential may lie in the generative AI generation, and how it may tackle some of the complexities we see. Let us look at some potential examples.

• Automating repetitive tasks
• Quickly scaffolding contract tests for users, can allow them to concentrate on the contract content, and intent of the test, rather than how to write the generic boilerplate required every time.
• Reducing human error
• By providing context of the code that is to be tested, generated code can ensure that that request and response expectations captured in the tests, match with the data used in the code, limiting stale data and ensure that tests can stay current, as API clients change.
• Predictive Insights
• Augmenting AI models. through RAG (Retrieval-Augmented Generation), with data points from your organization, such as API documentation, API observability (OTel or similar) and contract tests, would potentially allow users to interrogate the dataset in a way previously deemed highly exhaustive manually. Imagine for instance, a RAG AI creating a workflow diagram of your API’s, with the ability to drill down into individual service usage. If it could help you identify zombie API’s or reduce API duplication.
• We may see models with knowledge of contract testing or specific tools to provide guidance on the makeup of a contract test and highlight areas for improvement, acting as a contract-test pairing buddy.
• Improved time to market
• Contract testing tools themselves are ever evolving, with new feature requests, and issues being raised. Generative AI may allow for rapid prototyping of ideas and proof of concepts, to bring initial value to users. Once initial value is found, especially in the open source, we often find contributors will improve upon the solution, until it meets their needs. In this scenario, Generative AI would play a role in empowering and enticing users with some tangible code, rather than a GitHub ticket for a new feature request.

Now to be clear, this is not a definitive or exhaustive list. There will be many use cases to be discovered, ratified and validated. Hopefully, this may whet your appetite.

So, if this list is more aspirational, what about the here and now, as there are current tools on the market that offer AI capabilities, for all things, if you believe the marketing hype. In our next section, we will look at some of them along with the benefits & caveats.

Limitations of Current Generative AI Solutions

If you are a gamer, you will have noticed that graphics cards have been scarce for several years now, firstly snapped up by cryptocurrency miners, and more recently introduced in huge swathes in server farms all over the world. The reason has also made headline news and become dinner table conversation. It is of course Generative AI, whether its curated prompting via OpenAI’s ChatGPT, image creation by Midjourney, or code-creation via Microsoft’s CoPilot, everyone seems to have tried it in some fashion, even if it has been only for 5 minutes to pique their curiosity.

Large Language Models (LLM’s) are vast datasets which take time to curate and require vast amounts of data to be processed. Once these models are created, they are then released and used.

The software components that make up the building blocks of our applications evolve over time, interfaces may change, documentation will be updated, breaking changes will occur. Best practices may emerge, which are not within the documentation itself, but are passed on through users / blogs posts and other mediums.

Now if you consider that an LLM is a snapshot of a certain view of the world, at a certain point in time. It only knows the data is has been trained on, it is not topped up, as the world moves around it.

ChatGPT 3.5 for example, which is used in CoPilot is said to have a cut-off date of 2021.  

Most projects have had significant improvements and advances in the space of 3 years. In that time, the Pact contract testing framework has migrated from a Ruby shared core to a Rust shared core, and the client languages such as Pact-JS, Pact-JVM and others, have had DSL changes. New features have also been introduced to the Pact framework.

All of this knowledge is not present in the Generative AI models you’ll find on the market today, which means which they can generate a Pact test that looks plausible, it will either flatly refuse to compile with the latest Pact libraries or require you to leverage older versions of the code which is compatible.

Once we have the right versions of the libraries and corrected the DSL to allow the test to compile, we often find that Pact best practice is not being followed. The test may not generate provider states or leverage the power of matchers. The tests may be too strict, or too loose.

All of this diagnosing takes time, which detracts away from the main aim of writing the test in the first place, which in a Test-Driven development context, where Pact is often used, to apply pressure to the design of our code. We have many times found Pact (and other types of testing) have forced us to rethink how our code is structured, to make it more testable.

We understand that generative AI for creating the initial scaffolding for a test has great potential, but it requires up to date knowledge of the following to be truly effective:

• Pact Client Language DSL’s
• Pact Consumer test best practice
• Pact latest features
• Your own code, in order to ensure that the Pact expectations are correct, to avoid putting undue burden on your provider, in verifying the generated contracts.

Conclusion: AI’s Potential but Not a Silver Bullet

So wrapping up, generative AI offers a stepping-stone toward a more automated future in contract testing but is not the complete solution just yet.  

It could can aid practitioners engaging in contract testing in a multitude of diverse ways, helping them tackling their biggest pain points around the learning curve, test creation, maintenance and scalability however to fully leverage the potential, we would need to augment today’s solutions, by at least providing up to date knowledge of Pact’s client DSL’s, features, and best practices.

In our third and final post of this blog series, Matt Fellows will be explaining how the PactFlow team explored the value curve of combining contract testing and AI, to deliver a PactFlow AI-augmented contract testing solution builds to offer a more effective, specialized toolset for contract testing, you don’t want to miss it.

Thanks for reading, we cannot wait to see what you build!

Modern API Development is complex, to say the least. In a world driven by fast-paced, feature-focused delivery, teams often fall into the trap of relying too heavily on end-to-end (E2E) tests. These tests can provide high levels of confidence when they pass, but the vast scope of the tests can also make it difficult to diagnose failures.

This blog marks the beginning of our three-part “AI Automation” series, where we’ll explore how Generative AI is transforming contract testing, enabling developers and testers to address the challenges of complex API integrations with greater efficiency and accuracy.

Here’s what you can expect from this three-part series:

• Part One: Tackling API integration complexities with contract testing
• Part Two: How AI transforms contract testing and alleviates traditional challenges
• Part Three: Building the future of API contract testing with AI automation in PactFlow

Isolated Testing Leads to Redundancy

Tests are often spread across the full stack, with teams working in silos. When this happens, developers and testers often focus on different levels of testing, leading to overlap and duplication without improving code quality.

This issue is exacerbated by the growing focus on quality, with techniques like Test-Driven Development (TDD) and Behavior-Driven Development (BDD) becoming commonplace. While these approaches lead to more tests being written than ever before, a holistic view is integral to achieving quality at each layer of the testing pyramid.

Understanding the Testing Pyramid

To understand how contract testing can address these issues, let's consider a scenario where a "Collaborator" is a component responsible for communicating with another system. This could be tested in multiple ways:

• Component Integration Test: At the unit test level
• System Integration Test: At the integration test level
• End-to-End Test: Including UI tests and subcutaneous tests (which bypass the UI and directly access APIs)

Component Integration Test

In a component integration test, the external service is mocked. This allows the consuming team to build their application even when the external service is unavailable. These tests are run in isolation at a unit testing level, ensuring fast feedback with minimal dependencies. However, keeping the mock representation of the external service in sync with the real provider is challenging. This leads us to the next testing technique, system integration testing.

System Integration Test

A system integration test is traditionally conducted in a shared environment where both the consuming application and the external service must be developed and deployed. This coordination requires time and effort, as both services must be available in the same environment and may be influenced by external factors beyond the test’s control. If a test fails here, it could be because the mock used in the component integration test is out of date, or the provider has diverged from its initial representation.

End-to-End Test

Not all businesses view the APIs they create as the product they sell; rather, these APIs may power business-focused journeys that traverse multiple systems.  End-to-end (E2E) tests provide the highest level of confidence as they focus on user behaviors and ensure the entire system behaves as expected. However, since the system behaves as a black box, diagnosing the root cause of failures becomes extremely difficult. Designing systems with observability in mind can help with fault diagnosis, which is crucial for identifying production failures.

With APIs, it’s vital to know what is in use within your service catalog and how they operate in unison to deliver business value. Workflow specifications, such as Arazzo, can help tie business outcomes to the API journeys that deliver them. Subcutaneous testing can also be applied to concentrate on the API calls, bypassing the UI, which is often the slowest part of E2E testing.

Evolving Systems Gracefully

Contract testing is a technique that incorporates many of the advantages offered by the testing practices mentioned above. We can employ TDD techniques to write component integration tests, which create contracts between the API collaborator and the external service as a byproduct. These contracts clearly define the expectations of the consumer and can be shared with the external services the consumer depends on.

External services can use these contracts to ensure their applications honor the expectations set by the consumer. This approach helps prevent stale component integration testing mocks and offers providers valuable insights into which parts of their APIs are being consumed by whom.

To maximize the benefits and allow systems to evolve gracefully, contract generation and validation should be tied to continuous integration (CI). Consuming applications should publish new contracts, while providing applications must ensure that updated code honors existing contracts with service consumers.

This last point is critical, as it addresses a significant challenge: versioning. Versioning is both difficult and burdensome for service consumers and providers. Without a clear view of API surface area consumption, one must assume everything is in use, leading to bloated response schemas, multiple code paths to support versioned APIs, and customer confusion about what to use.

By tying contract generation to CI systems and tracking the code version that created it, we can monitor its deployment through various environments. This allows service provider developers to validate service consumer contracts across all current environments, enabling them to propose an evolution path for changes as the code is being written.

It's important to note that contract testing is a technique, and there are many ways to achieve it. Various tools offer contract testing capabilities, each with its own learning curve, which can sometimes detract from the true benefits of the approach.

The Complexities of Delivery

APIs rarely exist in isolation and have seen explosive growth due to the shift from monolithic to microservices architectures and the increasing number of protocols for message transmission.

According to industry research:

• 61% of API growth comes from microservices
• 81% of companies operate in a multi-protocol environment
• 57% use three or more protocols

APIs have become pervasive in modern life, powering everything from ride-share applications to social media platforms and government services. Yet, even mature organizations struggle with the impact of microservice sprawl.

Significant barriers still exist when implementing microservices or effective API-driven systems, such as:

1. Lack of experience or skills
2. Ever-increasing complexity of systems
3. Growing demands for faster delivery
4. Limited time due to heavy workloads

The Challenges of Contract Testing

Steep Learning Curve

Contract testing involves multiple layers and requires teamwork between API consumers and providers. It can replace existing tests, affecting ROI and requiring new skills. Since it’s a technique, not a tool, teams might need to create or adopt a solution, which could mean adjusting workflows, tests, or even the application. If done poorly, contract testing can do more harm than good.

Impact on the Delivery Lifecycle

Contract testing may require a fundamental shift in how teams develop today, which can initially impact delivery velocity. It also requires buy-in from consumer and provider teams and project stakeholders.

Scalability

As teams benefit from contract testing, they often become advocates within their organizations. However, spreading these practices consistently across the organization takes time and effort.

Creating and Maintaining Effective Tests

Creating an initial contract test can be difficult, especially as users may not know where to start. Ineffective tests can provide a false sense of confidence by either testing too little or testing the wrong parts of your code. At worst, they could bind a service provider to providing specific fields or endpoints that a consumer does not need.

It's also easy to miss key touchpoints for your code (e.g., point of change, pre- and post- deployment) for contract testing checks or to implement them incorrectly. This can cause updated consumer contracts to block service provider pipelines.

Beyond Breaking Changes: How Contract Testing Improves Software Design

Contract Testing and Methodologies

Contract testing aligns well with agile methodologies and is analogous to TDD for your APIs. TDD follows a pattern of red, green, refactor: write a failing test, write code until the test passes, and then refactor the code, knowing the test protects it. Contract testing follows this pattern by allowing a consumer to write a test specifying how they want a provider to behave in each situation. The consumer then writes code to implement that contract, ensuring they’ve issued the expected request. The mock provider returns a result according to that contract, allowing the developer to continue with unit testing assertions on their API collaborator.

Service providers can apply the same TDD concept on their side. They have a set of contracts showing the consumers’ expected behavior. The test framework should replay the requests to the provider’s code, which must satisfy each contract.

At this point, the developer can update the service provider’s code and replay the consumer contracts. Any discrepancies are identified, and the developer has the information needed to construct an upgrade path for consumers, avoiding breaking changes.

Agile & DevOps methodologies align neatly with this approach. On one hand, we advocate for small incremental changes to deliver value quickly; on the other, we want to ensure continuous integration and delivery, so we can push changes quickly to end users.

Contract testing complements this by providing fast feedback loops on incremental changes. This allows us to confidently manage and deploy these changes across environments with the knowledge from testing various combinations. These insights help keep system integration and E2E tests leaner, reducing the mean time to change in terms of delivering something to production.

Improved Development Workflows

Fast Feedback Loops on Coordinated Changes

Using a Pact Broker, teams can leverage webhooks to ensure provider verification is triggered when a consumer contract changes. The broker contains a list of all previous contracts and verification results and will pre-verify them if the contents haven’t changed.

If a change is detected, multiple webhooks are fired for each environment the provider resides in, guaranteeing that consumers get the quickest possible feedback. This instills the confidence to deploy at the point of commit, rather than waiting until after deployment to a system-integrated environment. This approach can be a significant time and cost saver when multiple teams or developers contend over a shared resource.

Can I Deploy

A queryable matrix is held in a Pact Broker to check whether contract tests have passed before deploying to a particular environment. This matrix can be set up to poll the results. When a new contract is published, and verification is pending, users can instantly deploy their applications once they are notified of the provider verification result that was automatically triggered.

Expand & Contract

Providing insights into field-based usage of an API gives developers an understanding of the impact of renaming a field, which might affect three out of six consumers.

From there, they can add an additional field and communicate to the three consumers to switch over. These consumers can publish their new contracts, which will then be verified, allowing them to deploy to production.

The developer can then run checks again and confirm that all consumers have stopped using the old field. This process allows it to be safely deprecated and omitted without requiring a version bump of the API or maintenance of two endpoint versions.

This information is invaluable in improving API comprehension and reducing field confusion for end users.

Bi-Directional Contract Testing

In traditional contract testing, there is an assumption that a service provider exists, and the consumer contracts are replayed against it, providing the highest level of confidence. This belief places a significant burden on providers to verify these contracts outside of the existing functional tests in the codebase. In some cases, the provider application is inherently untestable – perhaps a legacy application – or the codebase may not be accessible.

An alternative mechanism is bi-directional contract testing, where the consumer contract is statically compared against an API description document. This approach significantly simplifies the provider verification workflow and expands use cases for providers over whom you have no control, such as third-party APIs.

While this method offers fewer guarantees (since the static document may not fully align with the codebase it represents – a phenomenon known as provider drift), this risk can be mitigated to varying degrees depending on the approach taken.

A provider contract, as we see it, consists of two parts: the API description and the provider verification result (and associated documentation). This verification is primarily linked to the exit code of the provider’s test suite, but there is flexibility.

One major advantage of the bi-directional comparison provided by PactFlow is the ability for a provider team to transition from pr1esenting a provider contract to performing a traditional provider verification against their running application. This has proven particularly beneficial for organizations new to contract testing, especially those that have not yet convinced provider teams to fully integrate contract testing into their workflows.

Looking Ahead: The AI Advantage in Contract Testing

Contract testing is a powerful approach to managing the complexities of API integration, significantly reducing the risk of breaking changes and dramatically improving software quality. However, as we’ve explored, contract testing comes with its own challenges, particularly in scaling and maintaining effective tests. In the next installment of our series, we’ll explore how integrating AI into contract testing can overcome these hurdles, enhancing efficiency, accuracy, and overall software quality.

We are pleased to announce the updated user interface for PactFlow. Beautiful, simple, intuitive, and blazing fast, the new user experience is optimized around our recommended best practices.

Background

PactFlow evolved from the open-source Pact Broker. The original Pact Broker experience was built around the core concept of an "integration," which made sense at the time as we only supported Pact, a consumer-driven model where all contracts are aware of their counterparts.

Over the years, PactFlow has transformed into a feature-rich solution, including expanding the types of contract testing we support. For example, in bi-directional contract testing, we may not know both sides of the integration, yet we had to fit it into an integration-focused view. This approach also complicated the presentation of verification results, matrix, and compatibility information.

We've also introduced new concepts like branches, environments, deployments, and automation tools like can-i-deploy and can-i-merge. Presenting these within an integration-centric view led to multi-step user journeys.

Additionally, our design was inconsistent with other SmartBear API products. As we work towards our API Hub vision, our products must be tightly integrated to form a seamless developer experience.

With these challenges in mind, we decided to rethink the design from first principles.

A shift in perspective

Central to our vision is a shift to an application-centric, rather than integration-centric, view. Developers work on applications, and tools like GitHub and CI systems revolve around applications. By making the application the focal point of our product, we align better with the developer workflow and simplify connections to other products in the ecosystem.

Introducing the new UI

The new UI offers a beautiful, simple, intuitive, and blazing fast user experience, optimized around our recommended best practices. It retains all the key features you love, with some special additions:

• Application-Centric View: Focus on the application you’re working on.
• Workflow Integration: Deeper integration with key tools like can-i-deploy.
• Simplified Navigation: Quick access to application versions, integrations, and deployability.
• Improved Design: Enhanced usability and accessibility (WCAG 2.2).
• Light and dark theme support: one of the most requested UI additions is in!
• More Changes: Additional details and our migration guide can be found here.

Available Now

The new UI is now available to all customers on our SaaS plans and is the default experience. You can continue switching back to the old UI for now, but stay tuned for our announcement on when it will be decommissioned.

On-premises customers will see this introduced in the coming months.

We are thrilled to announce that the PactFlow interface has been updated to enhance your experience! Currently in an open beta, this new design makes navigating PactFlow more intuitive and efficient.

What's new?

• Application-Centric View: Simplified management of connections and workflows.
• Simplified Navigation: Easily find what you need.
• Enhanced Views: Quick access to application versions and deployment statuses.
• Improved User Interface: Designed for better usability.
• More Changes: Additional details can be found here, alongside our migration guide.

Try it out

To access the new interface, simply log in and click the "Try our New UI" button.

We're excited for you to experience PactFlow’s new interface and look forward to your feedback. In our beta period, we are actively seeking and responding to your feedback, in fact, we've already made several major updates as a result. You can do so via the widget in the navigation bar:

What's next?

In September, we will fully transition to the new interface. Until then, you can toggle back to the old interface as you get accustomed to the new one and as we continue to build out additional features.

PactFlow’s officially supported Developer API has just landed.

As you may be aware, PactFlow is built atop the excellent open-source Pact Broker, extending it with various enterprise features to help our customers implement contract testing at scale.

The Pact Broker has a feature rich API, which is a Richardson Maturity Model Level 3 compliant hypermedia API using the Hypertext Application Language (HAL) convention for modelling relationships between resources.

Benefits of Hypermedia APIs

Hypermedia APIs are "self-describing." An API client calls the root (/) endpoint and follows known links (called "relations") to perform various actions, such as creating applications, publishing contracts, or posting verification results. This allows resource URLs to change, and for the ecosystem to be more resilient. REST clients need little to no prior knowledge about how to interact with an app beyond a generic understanding of hypermedia.

In essence, it simplifies your experience, allowing for flexible integration with your systems.

This model has served Pact and PactFlow very well. For example, it allows us to add additional PactFlow-specific behaviour to existing API workflows without changing or impacting open-source clients. So well, in fact, the Pact Broker API has remained backwards compatible for 9 years whilst introducing huge amounts of change and supporting a large community of open-source languages, CLIs and SDKs.

An API with clearer documentation

However, despite the self-documenting capabilities of HAL, our customers have told us in no-uncertain terms that it is hard to understand what capabilities exist in our API, and how to use it. This lack of visibility has made it harder to build tailored solutions on top of our API and adapt it to their ecosystem.

In August of this year, SmartBear released SwaggerHub Portal, our API documentation solution that makes it super easy to take an OpenAPI document from SwaggerHub and publish a user-friendly API Portal. Unfortunately, we did not have an OpenAPI document to describe our API. Until now.

Introducing the PactFlow Developer API

Today, we are announcing the launch of the PactFlow Developer API, released alongside some of our other products in SmartBear's API Portal:

The documentation covers all of the basics you need to get started and integrate with our API:

The API provides access to a rich collection of resources and capabilities, including but not limited to:

• Contract Management
• User, Team, Roles and Permissions Management
• Webhook creation
• Matrix and `can-I-deploy` information
• Audit trail

...and much more.

Try it out in the browser

One of the handy features is the ability to call PactFlow APIs from your browser using the "try it out" feature. Just pop in your tenant name and your API token, and you can start to interact with PactFlow APIs in just a few minutes:

Use Cases

We've had many customer requests for all sorts of items - here are some ideas to get you thinking:

• Integrating user management and permissions with your custom onboarding processes.
• Creating a Maven plugin for X - "When all you have is a hammer, everything looks like a nail". Organisations that use Maven seem to need everything to be in Maven. Perhaps you would like to publish a provider contract (OAS) from Maven, record a deployment or delete a branch?
• Create a Jenkins Plugin (️️☝ see also Maven 🤣) or integrate deeply into another CI service.
• Build an SCM integration with GitHub, GitLab, Bitbucket to automatically delete old branches, report status checks or update PRs.
• Integrate our metrics data into your reporting dashboard, such as Splunk or Sumologic

Available Now

Our Developer API is available now to everyone on all plans. Head over to our API Portal to get started 👉 https://developer.smartbear.com/pactflow/default/getting-started.

💡 Do you have something you'd like to build using our APIs? Connect with us in Slack (register here) and we would love to chat with you.

Today, we're hitting a unique combo of emotions – a mix of joy for what lies ahead and a tinge of sadness for what's coming to an end.

Our wonderful Candy, the young and spirited software engineer who has been an integral part of our PactFlow family since 2021, is embarking on a new adventure.

From turning code into digital symphonies to crafting yarn into cute masterpieces, Candy has truly been a unicorn in our midst. Her ability to debug a tricky situation is matched only by her knack for turning a ball of yarn into something truly magical.

Juggling between code syntax and crochet stitches, Candy has shown us that life isn't just about tasks; it's about finding joy in what we do.

But here's the good news – while Candy might be bidding adieu to SmartBear and PactFlow, she's not leaving our Pact community – she is still a part of the journey (once you go Pact, you never look back!)

As we wave goodbye and wish her luck, we know that Candy's adventure is far from over. It's a "To Be Continued" that promises exciting quests, challenging levels, and untold surprises. Whether she's debugging lines of code or creating intricate crochet patterns, we're certain that Candy's journey will continue to be a tapestry of achievements and plenty of successes.

Candy, as you venture forward into the great unknown, remember that you're not just leaving our small (yet mightily) team; you're stepping into a world of endless possibilities.

Keep leveling up, keep crafting magic, and remember that our virtual doors will always be open for you. You've been more than a colleague – you've been a friend, and a bundle of positive energy that's made our days better.

Here's to Candy – the coding connoisseur, the crochet queen, the gaming guru, and the vibrant spirit of our team since 2021. We'll miss you, but we're excited to see you conquer new horizons.

Until our paths cross again,

Your PactFlow Family

In April 2022, SmartBear acquired PactFlow, adding contract testing to our API platform. This meant different things for our company, but for me it meant diving head-first into the contract testing methodology and the Pact framework. This was so I could become fluent in explaining it to software development teams whose only experience with Pact might be a blog post or hearing it mentioned in conversation. Simple, right?

Thankfully, there were plenty of workshops and articles to help me learn the ropes. Once I had a solid understanding of the fundamentals, it was time to start talking to teams interested in the technology, then help them figure out if contract testing could solve some of their software delivery challenges. With over a year’s worth of conversations, I’d seen many success stories, but I also saw plenty of teams and companies who couldn’t fully unlock the value of contract testing. In the latter scenario, it’s usually down to one or more of the following things:

1. The return on investment wasn’t clear enough

When I’m supporting a team with their contract testing proof of concept (POC), the first thing I ask them to do is review their integration test suites. The primary value of contract tests comes from the fact that, in the long run, they’re cheaper to run and maintain than traditional end-to-end integration tests. Ahead of a POC, I’ll ask teams to think about how much time they currently spend on things like:

• Building and maintaining test environments
• Writing and executing integration tests
• Debugging integration tests failures
• Fixing flakey integration tests

This will give the team and the wider organization a clear idea of the value of contract tests, specifically how they save development and compute time while providing faster feedback. Once these metrics are well-defined and understood, it’s easier to communicate to other teams the return on investment contract testing can provide.

Ask one of the friendly SmartBear sales team for your own PactFlow POC template – a customizable tool to help you set out your POC goals in advance to convey the return on investment.

2. The purpose of contract tests wasn’t defined well enough

I’ve lost count of the number of times I’ve said it over the last year; contract tests aren’t functional tests. The best analogy I’ve heard so far goes like this:  

Let’s say I walk up to you on the street, hand you an envelope and ask you to post it for me. A contract test would verify you understood my request, but wouldn’t verify you  post the letter, the letter reaches its destination, or that I get a reply, etc.

Those things (we could call them system side effects) would be better verified by using functional tests. Ideally, contract tests focus on the messages flowing between a consumer and provider and ignore other elements of the system. A misunderstanding of the purpose of contract tests can lead to frustration amongst the developers and testers who are tasked with writing and maintaining them.  

This blog demonstrates the purpose of contract testing in the context of the testing pyramid conveying the difference between unit, integration, E2E and contract tests.

3. The scope of your contract tests was too wide

The best examples of contract tests will focus on the data access layer of the consumer and, even more specifically, the part of that layer we would consider the API client. If I’m working with a team that isn't immediately sure what part of their code this is, I ask them the following question:  

What part of your code is responsible for translating your application’s business domain objects and data into HTTP requests getting sent to the provider?

That’s where contract tests are going to be most effective. A good contract test shouldn’t be interested in the consumer’s business logic or the provider’s business logic - that would still be the realm of the respective teams’ functional tests. The risk here is, once again, teams get frustrated with brittle and difficult to maintain contract tests which, if you remember from earlier, are exactly what we’re trying to avoid.

4. There wasn’t enough communication between consumers and providers

A less technical, but no less important, reason I see organizations fail to maximize the benefits of contract testing is due to poor communication between the teams involved. One benefit of contract testing is you can decouple teams that otherwise would depend on (and potentially be blocked by) each other’s work. However, contract testing isn’t a substitute for open and easy communication between different development teams within an organization.

For example, I’ve had conversations with provider teams who are eager to implement contract testing with Pact and PactFlow but who don’t have lines of communication open with the consumer(s) of their application. Worse, they can’t tell me who these consumers might be. It takes two to tango, and in the world of contract testing, both sides of an integration need to be sold on contract testing for it to provide value to the organization.

Having a shared understanding of the value means consumers and providers need to be able to communicate and collaborate effectively. This can also result in a lack of buy-in and integration into your organization’s engineering culture. A lot of the companies I work with see pockets of success but struggle to unlock the next level of value because contract testing isn’t truly part of their ways of working.

Some ways to facilitate this are setting up communities of practice and internal templates/educational materials tailored to your organization’s tech stack and business domains. Without these mechanisms, you’ll struggle to embed contract testing at your company.

5. You didn’t know about the Pact Foundation Slack workspace

Finally, a shameless plug. PactFlow wouldn’t exist without the work of the community behind Pact. The Pact Foundation Slack workspace is filled with nearly 5,000 practitioners who are hands-on with the various implementations of Pact and the related technologies (such as the open-source Pact Broker and PactFlow.) The invite link to this workspace is one of the first things I’ll send to a team embarking on a contract testing POC, because it’s the best place to look to get answers to implementation-related questions from people who have done it before and seen positive results.

So, you’ve read some articles, watched some videos, talked to colleagues who’ve done it before and you’re ready to find out if contract testing could save time and money for your team. Keep these five points in mind, and you’ll be in Pact Nirvana in no time!

Getting started:

• Create a free PactFlow account to spin up your POC in no time
• Complete the contract testing courses in the SmartBear Academy and get your contract testing certification