Hey everyone! 👋 I'm hoping to get some community feedback on my company's approach to contract testing, as it feels quite different from my previous experience. I want to make sure we're on the right track. Here's a quick rundown of our current setup: • Consumer Side: When consumers generate contracts, there isn't a verification step against a mock service. The consumer code doesn't seem to be asserting its expectations before the pact file is created. • Provider Side: For verification, we send the requests from the pact file directly to a live, deployed environment called "temp". This is a task-based environment that contains recent feature changes. We are not using mock servers or any test doubles; it's a real, running env with services. • Centralized Repo: All contract tests for all our services are being written in a single, centralized repository. My main concern is the dependency on a live environment for provider verification. This feels less like a contract test and more like a targeted integration test. The core benefit of testing components in isolation seems to be lost. So, my question for you all is: Is this a valid implementation of contract testing? I'm worried that by relying on a live environment, we're missing out on the speed, reliability, and independent deployability that contract testing promises. It feels like we're just asserting a response from a live server, which doesn't seem to be the point. Any thoughts, advice, or validation on this would be hugely appreciated! Thanks in advance.

Hi guys, I am promoting contract testing in my company, and need more strong evidence to persuade other engineers to adopt it. Can someone share some context and scenarios about why you used contract testing, and what pain point it resolved in your company? Really appreciate. 🙏

blobwave Hey all, I am sure some of you have been exploring AI, maybe you’ve been exploring it with Pact? I’d love to hear how your experiences have been, good, bad or indifferent. If you have any ideas for areas where AI could be leveraged to improve your Pact experience, be sure to let us know. 🤖 💛

Hi all, would love to know if there's anywhere I can keep tabs on to keep up to date with progress of the V2 plugin interface? I suspect not much is happening towards it right now as it's very difficult to track anything recent down 😄

Hello, We are implementing bi-directional testing in some of our projects, but it's not clear to us how the contract matching is done between consumer versions, provider versions, and different environments. For example, is the environment matching one-to-one (i.e., consumer 'dev' with provider 'dev'), or are they separate? Can a consumer in a 'dev' environment match with a provider in 'production', for instance? And how do we control that? Thank you.

Hey there everyone! I have a question on the flow of working with pending pacts. We just ran into a problem, where the pact was verified on a feature branch and the results were published to the broker as part of the pipeline. This causes the provider tests on most other feature branches to fail. The documentation (and from I can tell the code as well), a pact is verified if either a) The contract has been verified on this branch before. b) The contract has been verified on any branch, that existed before this branch. Does this mean, the other feature branches would need to wait for the branch that originally verified the contract to be merged? Or shouldn't a feature branch upload verification results in the first place? For context: • the consumer team hasn't fully finished up setting their pact configuration and so far has only published pacts for their tagged versions (where the providerBranch is also set to the Tag). Their main branch in the Pact Broker is not yet set. • we are using WIP pacts What are we doing wrong?

Hey everyone, Does anyone have any experience guidelines or tips for measuring the coverage of our pact tests? As part of our transition to pact we have added tests for most of our consumers, and we believe we are pretty far. However we are looking for a way to measure the coverage from the consumer perspective. Since we'd like to know how many integrations are still missing tests. How do other deal with this?

Hi all (sorry for a long message) We’re using Pact.Net with the following setup: 1. One system consisting of: ◦ Client-side UI ◦ Web API BFF ◦ The BFF has a couple of GraphQL dependencies downstream (these are our Pact providers). 2. We run UI tests against the BFF and use Pact to mock the downstream GraphQL providers (Pact.Net consumer tests generate the contracts). 3. We then run provider verification against these contracts for the GraphQL services. Our challenge is around _IDs_: • The UI tests use static IDs in GraphQL queries (e.g.

room(id: "123")

), and these IDs are recorded in the pact. • When we run provider verification, those IDs usually don’t exist in the provider’s real database. • We have a provider state setup tool that runs mutations to create test data, but the provider uses identity/auto-generated IDs, so the IDs returned from setup don’t match the hardcoded IDs in the contract. Conceptually, we’d like to: 1. In provider state: run a mutation to create test data and let the provider assign an ID. 2. In verification: use the ID returned from setup in the GraphQL request for that interaction. Questions: 1. Is there any supported way in Pact for provider state output (e.g. a newly created ID) to influence or substitute into the request during provider verification? 2. If not, what’s the recommended way to handle this pattern of: ◦ Consumer/UI tests that send static/example IDs ◦ Providers that rely on auto-generated identity columns?

Hi everyone, I need some help understanding the relationship between the "Pending Pacts" feature described here and the "pending" field that can be configured inside the "interactions" section of a contract definition. You can see it here . From the "Pending Pacts" documentation, I understood that the pending status of a contract is calculated automatically and dynamically by the Provider (as explained here ). Because of this, I cannot understand if or how the "pending" field inside the interactions is considered, since it can be set by a Consumer when defining a contract. What am I missing? Thanks a lot.

Happy New Year!

Hello a general question : • Do you advise using PACT for queues and API contracts even when not doing it from the start and the project is already quite mature but suffers contracts issues? If so any documented best practices or real experiences feedbacks? • Planning to move from JSON to Protobufs does this means a lof of efforts converting existing tests based on json or can tests be developed in a resilient way to formats from scratch?

Hey, looking for advice on using pact contract testing for event driven services. The standard Pact consumer-driven model requires the consumer to explicitly name each provider in the contract. In event-driven systems, the consumer typically only cares about the topic and the message shape, not which service produced it. This creates friction every time a new producer comes along, because it requires a change on the consumer side just to add the named pairing. Has anyone tackled this by modeling the "provider" as the topic itself rather than the producing service? The ideal end state would be something like: a provider declares it produces to a topic, a consumer declares it consumes from that topic, and verification runs automatically across all providers mapped to that topic — no consumer changes required when a new producer onboards.

👋 Hi everyone!

I am a Web3 full-stack blockchain engineer. Recently, I came across your Github commits and was very interested in what you are doing.

I 'd like to contribute to your project

Join John Romero, for SmartBear’s BIG reveal on March 18th! Meet John Romero, co-founder of id Software and creator of some of the most influential games ever (DOOM, Wolfenstein 3D, Quake). He will be joining our big reveal on March 18 at 11:00 AM ET. During the event, we’ll unveil our solution for tackling software quality at AI speed, and John will share his perspective on building software that performs at scale. Attendees will have the opportunity to ask John questions during the live Q&A, gain insight from a true industry leader, and even have a chance to win signed swag along the way! Don’t miss this livestream, it is the reveal everyone will be talking about! Sign me up! The SmartBear Team.

Has anyone got any resources on using Pact to test compatibility of JSON documents written and read from S3? Alongside RabbitMQ, our app shares data using various S3 buckets and we've suffered serialisation / deserialisation issues. I wondered whether Pact can be used here? I assume so, but perhaps without direct library support?

Is anyone based in Boston, or the wider Massachusetts area? If so, feel free to share this role with your network, thank you 🙂 https://pact-foundation.slack.com/archives/CKG0YV5EF/p1776085417335629

Hi folks, here's a set of PRs to add

arrayContains

matcher to plugin matcher language and implement it in protobuf plugin. I don't have enough context to implement it in other plugins (nor have I a definite list of all available plugins), not sure what's the best way to handle such a change. https://github.com/pact-foundation/pact-reference/issues/523 - adds arrayContains to pact_models https://github.com/pactflow/pact-protobuf-plugin/issues/236 - implementation in protobuf plugin (draft since pact_models needs to be released first) https://github.com/pact-foundation/pact-plugins/issues/95 - grammar docs All PRs are done by AI of course, so please let me know if there are any issues 🙂

Hello all! 👋 We currently define our API response models using Zod schemas, and we’re duplicating the same structure again in Pact matchers. For example, instead of defining a response in Pact like: account: { email: MatchersV3.string('user@automated.testing')} we already have an Account object defined in a Zod schema that describes the same fields, types, and nullability. Is there a recommended way to reuse or derive Pact contracts (or matchers) from existing Zod schemas, so we don’t have to redefine the same response objects in Pact and risk schema drift? Or is the expected approach to define the response shape explicitly in Pact and treat the contract as the single source of truth? Many thanks! :)

Hey folks ralph wave Is anyone aware of a Claude Skill (or Copilot extension / Cursor rule / any similar AI tooling, tech-agnostic) that helps developers write Pact contract tests? we're trying to accelerate Pact adoption across our org. Devs are generally on board, but the initial "how do I write my first consumer test" step tends to be where momentum stalls. An AI assistant that could scaffold consumer tests from an existing API client, suggest matchers, or generate provider verification stubs would be a big unlock for us. (what I've found online so far isn't worth paying attention to) Would love to hear if anyone has built something, found something, or has opinions on whether this is even the right approach 🙏

Hey everyone 👋 I ran into something with Pact Broker and monorepos, and wanted to check how others are handling this. We have a pretty typical setup: • 1 consumer app • A provider that lives in a monorepo, split into multiple microservices In Pact Broker, those microservices show up as separate provider pacticipants (we currently have 4). The issue is: Whenever a contract changes, Pact Broker triggers a webhook for each provider pacticipant — so we end up with 4 webhook calls. All of them hit the same CI pipeline, which means the exact same pipeline runs 4 times in parallel 😅 What we’re trying to achieve is basically: → run the pipeline once per contract change, not once per provider Right now we’re handling it on the CI side (Azure DevOps concurrency / locks), and also considering putting a small webhook gateway in front to deduplicate events. But I was wondering: Is there any Pact-native way of dealing with this in a monorepo setup? Or is the general expectation to handle this kind of deduplication outside of Pact? Curious how others approached this in real projects 🙏 Thanks!

Hi folks, A question on achieving Pact Nirvana with pending pacts. When provider CI runs, there are two cases - main branch or PR branch. On main branch (we use go lingo) we have: • EnablePending = true • IncludeWIPPactsSince = wipPactsSinceDate() // returns reasonable date • and we obviously publish the results Question on the PR branch we have questions: • IncludeWIPPactsSince - we have this unset, because consumers can have tons of PRs and idk if we want every provider PR build to verify against every consumer PR build, but this might be premature optimization • EnablePending - this one I'm confused about. We don't want provider PR build to fail because of a pending consumer pact; but we also don't want provider PR build to be the first one to mark the consumer contract as non-pending, by publishing first verification result to the broker (because as I understand this, first verification => no longer pending?) • with the above in mind, maybe we shouldn't be publishing verification results from the provider branch? we invoke

can-i-merge

after running both consumer and provider tests though, and if we don't publish results, idk if that's gonna work correctly? Thanks!

does atMost(1) matcher rule break postel's law? Because let's say atMost(0) that's probably not allowed, because you're basically saying "return empty list", which is akin to say "return no list" which breaks this https://docs.pact.io/getting_started/matching/gotchas#you-cannot-expect-a-field-to-not-be-present-in-a-response but does saying atMost(1) also break the clause "you cannot test for absence of something", cause you're testing for absence of elements beyond 1?

Hey again, we're implementing bi direcitional contract testing in order to ensure backwards compatible releases, but struggling with how to enforce backwards compadibility. We have a FE and BE We could enforce that any merge to main is compatible with the opposite service main branch contract AND deployed to prod contract. But this means if we want to do a breaking BE change (removing an endpoint), we have to wait until the new FE (without the endpoint call) is deployed to prod until we can merge that PR. This would ensure that if that FE does not deploy until BE is ready for it, and it can safely rollback But this really slows down devs, they can't merge their pr until BE is in prod. We could have seperate can i merge and can i deploy checks, Prs do can-i-merge with the opposite main contract, and Deployments check if the contract is compatible with the opposite prod contract, but this means that we could have a issue only when we start the release process, when we notice that new version of BE is not compatible with old version of FE. Is this just generally expected, as in devs should always code backwards compatible, and if they don't its going to show up at deploy time. Or should we just block at merge, devs need to make sure everything into main could be deployed instantly, so it's on them to make it backwards compatible or wait until the new version of the BE is out. thanks For context we usually deploy FE and BE at same time, but want to be able to deploy independently, so we need to check new FE works with old BE and vice versa

Question about

can-i-deploy

with optional provider dependencies. We have applications that receive events, and therefore have async message contracts. They consume events sent by a provider. However our setup has multiple production environments where some applicaitons may not need to be deployed. Lets say Application A (consumer) receives events from Application B (provider). Is is possible to use

can-i-deploy

so that applicaiton A can still deploy even when application B is not deployed to the environment at all? I see that the cli has an

--ignore

flag. But that is not really what I want, since that would ignore the provider alltogether (and I do require can-i-deploy to succeed if a deployment exists for applicaiton B)

pactflow platypus slack Josh has put together a helpful short video on using AI with Pact, with a simple reminder to plan before you prompt.

We’re collecting best bug stories and would love to hear yours.

It worked yesterday

Today it has other plans

Welcome to Monday

What’s the most memorable bug you’ve ever found (or accidentally introduced)? Reply in the thread with: • Your favourite bug you’ve ever found (or accidentally created!) • Why it was memorable • What you learned No proprietary code please. Keep examples anonymous and avoid sharing confidential information. Entries close on Friday, 31 July. We’ll select our three favourite bug stories and announce the winners the following week. The top three entries will receive a prize and be featured in our community showcase.

pactflow platypus slack AI Tip 2 - For pull requests, let your AI agent take the first pass before your team ever sees it. Thanks to @Ilia for this insight 🙌🏻

webinar*Webinar* webinar The AI ROI Gap: A Fireside Chat on API Governance for Engineering Leaders 📆 Thursday, August 13, 2026 at 3:00 PM BST This fireside chat explores how organisations can maximise the value of AI coding assistants by pairing them with strong API governance. Learn why speed alone isn't enough, how poor governance can erode ROI, and how integrating AI with tools like Swagger helps teams build faster without sacrificing quality or control. Join Mark Boyd (Platformable) and Dariusz Stoklosa (SmartBear) as they explore how combining AI coding platforms with Swagger helps teams move faster without sacrificing quality or control. You'll learn: • Why AI alone doesn't guarantee ROI • How API governance accelerates AI adoption • A practical approach to integrating Swagger into AI-assisted development Whether you're leading engineering teams or evaluating AI investments, this session offers practical insights for building AI-enabled development that scales. 👉🏼 Register to join