Frequently asked questions


Questions about the product and use cases

What is Pactflow?

At its core, Pactflow is a managed version of the Open Source Pact Broker, with added features for teams and enterprises looking to scale their contract testing.

Pactflow allows teams to increase their application quality and time-to-market by speeding up the release cycle for large-scale integrated systems. Whether you build microservices, messaging systems or cloud native (e.g. lambdas) systems, Developers and Testers can write simple, isolated unit tests for each integration in their application and generate API contracts that are guaranteed to be up-to-date with their code, ensuring all dependencies are always compatible.

This unit test approach is simpler, faster and more reliable than traditional end-to-end acceptance tests for a variety of use cases, and can be integrated easily into a holistic testing strategy.

What is the difference between Pact, the Pact Broker and Pactflow?

Pact is an open source tool implemented in multiple languages that allows you to perform contract tests on an integration point using a simulated provider and a simulated consumer. It runs on your local development development or CI machine for the duration of the Pact tests.

The Pact Broker is a permanently running, externally hosted application with an API and UI that allows you exchange the pacts and verification results that are generated by the Pact tools. Like Pact, it is open source software.

Pactflow is a commercial fork of the Pact Broker, and adds features required to use Pact at scale. These include SSO, user management, an improved UI, and secrets.

Who should use Pactflow and why?

Pactflow is designed for developers, QA teams and engineering managers who are building, testing and supporting distributed systems - such as web applications based on a microservices architecture.

Modern product engineering typically involves numerous, often distributed teams, requiring an effective collaborative workflow to evolve the design of their APIs.

Pactflow addresses this challenge, by enabling a seamless workflow to share contracts between teams, visualise their dependencies and integrate their CI, whilst reducing the administrative burden of managing extra servers for tooling.

What are some typical use cases?

  • HTTP based API microservice architectures
  • Event based architectures based on message queue and publish-subscribe, such as Kafka, AWS Kinesis, Azure Event Hub
  • Cloud based applications, including use of FaaS products such as AWS Lambda, Azure Functions Google Cloud Functions
  • Data engineering - making implicit contracts in streaming data pipelines explicit, and ensuring contract enforcement between components
  • High performance APIs with protocol buffers
  • IoT - high volume messaging from sensors and devices

What languages does it support?

  • JVM - Java / Kotlin / Groovy / Swift / Scala
  • Ruby
  • Golang
  • NodeJS / JavaScript
  • Python
  • Objective-C / Swift
  • .NET
  • PHP
  • C++ (consumer only)
  • Rust

Can I test cloud services such as Lambda, Kinesis?

Yes - see above!

Can I use it with Message Queue technologies?

Yes - see above!

How does it work with Pact and Spring Cloud Contracts?

Pact and Spring Cloud Contracts are API contract-testing tools that produces contracts. Pactflow manages the lifecycle of these contracts, and provides a workflow to manage them in your continuous delivery pipelines.

What is a System Account?

System Accounts, sometimes referred to as Service Accounts or Machine Users, are a type of account that can only be used for API access to PactFlow.

They are designed for machine-to-machine use. In PactFlow, they are primarily used for integrating with CI/CD systems (such as Github), but may be used for automation, reporting or other integration use cases.

As System Accounts are not tied to a specific user (e.g. an employee), they are not predisposed to tokens suddenly expiring when the user leaves the company, leaving a trail of broken systems in their wake.

They are not permitted to be used as a replacement for real users (i.e. people) who work with PactFlow - they must have their own dedicated User account. For some example use cases, see the following section 👉.

System Account: Examples

Example 1 (incorrect): Steve creates a System Account for a new team, and shares the API Token with his team members so they can run their Pact tests locally using a shared credentials.

This is both a violation of our terms and conditions, and a security risk - if one of the team members leaves, Steve will need to rotate the token, and update all of the other team members with the new token. In the mean time, the departed member may still access PactFlow.

Example 2 (correct): Sally creates a System Account for accessing PactFlow in their GitHub pipelines.

This is the correct useThis way, if Sally ever leaves the organisation the GitHub builds won't start failing suddenly.

Is it compatible with the Open Source Pact Broker?

Yes, we a fully backwards compatible with the Open Source Pact Broker. We contribute regularly to the Open Source roadmap, and generally release multiple updates a week to our customers.

If you need help migrating from a self-hosted broker, please contact us.


Questions around pricing plans

Do you support invoiced billing?

Yes, we support billing for annual plans on our business and enterprise tiers. Contact us so that we can set this up for you.

How can I upgrade from the Developer (free) plan?

You can upgrade from within the application under Settings > Subscription

If you need to migrate data, please raise a support ticket and we'll take it from there.

Do you store any credit card information in your systems?

No. All credit card activity and information is handled by our third-party provider, Stripe. See Stripe’s Terms and Services.

What counts as a User for billing purposes?

Our plans use a "seat" based model, where you purchase capacity for how many Users you need and assign them as required.

A User is considered any person (human) that requires independent access to the system. For example, if you have two team members Sally and Billy that will be logging into the UI, as well as a separate dedicated CI user for automation, you will need two seats to cover the users - you may create a System User to cover the CI integration (note: limits apply depending on the plan you use).

Each user gets a read-only and read-write API token that can be used for automation (e.g. for use in CI or local verification testing). Users are able to rotate these tokens as needed.

Can each team member see applications and integrations created by other users?

Yes. All users contribute to the same system, they are simply separately authenticated.

What are the various authentication modes?

Users may login with their GitHub credentials (via OAuth2), a Google email domain or standard login (user/pass).

Our Business and Enterprise plans have the option for SAML 2.0 authentication.

For CLI automation, any user may also create API tokens for use by standard Pact Tooling.

Do you provide an on-premise / self-hosted option?

Yes! Our Enterprise plans are a drop-in replacement for the open source Pact Broker, with all of the key features of our SaaS offering1.

1. On-premise deployment currently only supports SAML 2.0 authentication mode

Can I migrate my self-hosted Broker to Pactflow?

Yes you can. If you'd like to retain your historical data, contact us and we'll help you through the process.

I didn't receive my signup / confirmation email

We send sign-up and password confirmation emails from the address
via (our email provider) - we have SPF and DKIM records setup to increase the trustworthyness of our emails. Please check your spam filter, or confirm with your email Administrator that our emails are not being blocked. If you're still having issues, please contact our support team and we'll do our best to help.


Questions around security and data protection. For detailed security information, visit our dedicated Security page.


How secure is your solution?

We take security seriously. In addition to 3rd party penetration testing, we perform regular security scanning of our platform, encrypt all data at rest and use TLS for all remote communication. Each customer is further isolated via separate database instances. Learn more about our security practices.

Can I host my own Pact Broker?

Yes, you can manage your own Pact Broker, however you will be responsible for its operation, including security, maintenance and upgrades. Pactflow is a fully-managed, highly-available, and hardened deployment of the open source version with an improved user experience.

Do you provide a list of IP addresses/ranges that we can use to lock down access to our (CI) systems?

Yes, you can find our IP whitelist here

Does the underlying data store encrypt, or otherwise protect, the published pacts?

Yes there are a number of strategies we employ, which can be briefly summarised as follows:

  • We use AWS as our underlying infrastructure stack, and follow the guidelines of the Well Architected Framework including standard security protocols
  • Each customer on the platform has their own isolated database with separate sets of credentials
  • All data is encrypted at rest
  • No customer has access to other customers' data
  • We recommend that contracts do not contain any sensitive data (e.g. PII) and contain structural example content only, using tools like Faker.

What will Pactflow do with the contracts or any other data that is uploaded to the service? Will they be harvested and/or shared in any way?

We don't share the data with any third party, anonymised or otherwise. To provide our service, we of course need to analyse the contents of pact files and other interactions with our service to be able to provide the features. All data is encrypted at rest, and no customer has access to other customers' data.

Please read our terms and conditions for further clarification on our non-disclosure policy.

How can we protect secrets we put into the Pact Broker required to get the webhooks to work?

Use our Secrets feature. All secrets are fully encrypted against a customer specific key.

What are the ways we can best manage our own inbound and outbound access re: the Pact Broker and our hosted CI server?

We support multiple access methods: username and password, social login via GitHub and Google, as well as SAML authentication.

In terms of network access, the only deployment topology supported is HTTP+TLS access over the public internet.


Questions GDPR and Compliance

Do you have a Data Protection Agreement (DPA)?

Yes, as a Data Processor we take privacy of your data seriously, and have included a GDPR addendum in our standard terms and conditions

It is worth repeating here that Pactflow is not a service designed to store sensitive personal or PII related data, aside from basic customer registration details.

Who are your Data Processors?

You can find our full list of Data Processors that we have Data Processing Agreements (DPA) with at our dpa page

Are you GDPR compliant?

Yes! If you'd like to know more, please contact us.

Are you SOC 2 compliant?

Yes! PactFlow is SOC 2 Type 1 compliant. You can read our full list standards and compliance policies on our security page.

arrow-up icon