API Contract Testing — Automated on Every Pull Request
Traditional contract testing requires writing and maintaining test suites. CodeRifts uses your OpenAPI spec as the contract and validates every change automatically — no tests to write, no Pact broker to manage.
Traditional Contract Testing vs. CodeRifts
| Aspect | Traditional (Pact, Dredd, etc.) | CodeRifts |
|---|---|---|
| Setup time | Hours to days | 30 seconds |
| Tests to write | One per consumer | None — uses your spec |
| Maintenance | Tests break when API changes | Zero maintenance |
| Broker required | Yes (Pact Broker) | No |
| Breaking change detection | Only tested contracts | All 61+ change types |
| Risk scoring | No | 0–100 per PR |
| Policy enforcement | No | Naming, versioning, security |
| Works with | Language-specific SDKs | Any language — spec-based |
What Gets Checked on Every PR
CodeRifts compares the base branch spec against the PR branch spec and generates a comprehensive report.
Breaking Changes
Endpoint removals, type changes, required field additions, auth changes — 10 categories, 61+ patterns.
Risk Score
Multi-dimensional score (0–100) based on change severity, blast radius, and affected endpoints.
Policy Violations
Naming conventions, versioning rules, deprecation timelines — all configurable per repo.
Security Analysis
OWASP API Top 10 alignment, auth coverage, sensitive field exposure detection.
Semver Recommendation
Suggests the correct version bump (patch, minor, major) based on the changes detected.
Auto Changelog
Generates a human-readable changelog entry for your release notes.
How It Works
Install the GitHub App
One click. No config file required. CodeRifts auto-discovers your OpenAPI specs.
Open a pull request
CodeRifts compares the spec on your PR branch against the base branch automatically.
Get a detailed report
A PR comment with breaking changes, risk score, policy violations, security analysis, and a suggested version bump.
What Is API Contract Testing and Why It Matters
API contract testing is a technique for ensuring that two separate services can communicate with each other without having to run full end-to-end integration tests. It captures the interactions between a service provider (e.g., a backend API) and a service consumer (e.g., a frontend web app or another microservice) in a document called a "contract." This contract defines the expected requests and responses, including data structures, status codes, and headers.
In a modern microservices architecture, where dozens or even hundreds of services interact, contract testing is crucial. It allows development teams to work independently and evolve their services with confidence. By validating changes against the contract, teams can "shift-left" the detection of breaking changes, catching them early in the development cycle (during pull requests) rather than late in the QA or production stages. This prevents the widespread failures that can occur when one service deploys a breaking change that affects its many consumers.
Contract Testing vs. Other Testing Approaches
| Testing Type | Purpose | Speed | Cost & Complexity |
|---|---|---|---|
| Contract Testing | Ensures two services can communicate based on a shared contract. | Fast | Low |
| Integration Testing | Verifies that multiple services work together in a live environment. | Slow | High |
| End-to-End (E2E) Testing | Simulates a full user journey across the entire application stack. | Very Slow | Very High |
| Unit Testing | Tests individual components or functions in isolation. | Very Fast | Very Low |
Consumer-Driven vs. Provider-Driven Contracts
Consumer-Driven Contracts
In this approach, the consumer of an API writes a "contract" that specifies the exact parts of the API it needs to function. The provider then runs tests to ensure it fulfills the terms of all its consumer contracts. Tools like Pact are popular for this workflow.
Pros: Ensures the provider doesn't break existing consumers.
Cons: Can be complex to manage, requires a central "Pact Broker," and tightly couples the provider to the consumer's implementation details. The provider can't easily deprecate fields because it doesn't know if a consumer still relies on them.
Provider-Driven Contracts (Schema-First)
In this approach, the API provider defines the contract using a formal specification language like OpenAPI. This specification is the single source of truth for the API's behavior. The provider is responsible for maintaining and evolving the spec.
This is where CodeRifts fits in. By using your OpenAPI specification as the contract, CodeRifts validates that any proposed changes are compatible with the existing contract. It acts as an automated guardian of the provider's public interface.
Pros: Simpler workflow, single source of truth, enables automated tooling like CodeRifts.
Cons: Requires discipline to keep the specification accurate and up-to-date.
Frequently Asked Questions
What is API contract testing?
API contract testing is a method to ensure that services (like a microservice and its client) can communicate with each other. It verifies that both sides adhere to a shared "contract" without the overhead of full integration tests.
How is contract testing different from integration testing?
Contract testing checks API integrations in isolation, verifying that a provider offers the endpoints and data structures a consumer expects. It's fast and focused. Integration testing is much broader, slower, and more brittle; it spins up multiple services to test their actual interactions in a live-like environment.
What tools are available for API contract testing?
For consumer-driven contract testing, the most popular tool is Pact. For a provider-driven, schema-first approach, you can use your OpenAPI specification as the contract and a tool like CodeRifts to automatically detect breaking changes on every pull request.
How does CodeRifts enforce API contracts?
CodeRifts uses your OpenAPI or Swagger file as the definitive contract. When you open a pull request, it compares the spec in your feature branch to the one in your base branch. It then reports on any breaking changes, policy violations, or security risks, effectively enforcing the contract before any code is merged.
Do I need contract testing if I have E2E tests?
Yes. End-to-end (E2E) tests are slow, expensive, and flaky. They are poor at pinpointing the exact cause of a failure. Contract testing provides fast, precise feedback much earlier in the development process, allowing you to catch integration-breaking changes before they ever reach a staging environment. This allows you to run fewer, more targeted E2E tests.
Stop writing contract tests. Start enforcing contracts.
Free for up to 3 private repos. No credit card required.