API contract testing — automated on every pull request
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).
- Auto changelog — Human-readable changelog entry for release notes.
What is API contract testing?#
API contract testing is a technique for ensuring two separate services can communicate without running full end-to-end integration tests. It captures the interactions between a provider and a consumer in a document called a "contract," defining expected requests and responses, data structures, status codes, and headers. In a modern microservices architecture, contract testing lets teams work independently and evolve their services with confidence — catching breaking changes early, during pull requests, rather than late in QA or production.
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 multiple services work together in a live environment | Slow | High |
| End-to-End Testing | Simulates a full user journey across the entire stack | Very Slow | Very High |
| Unit Testing | Tests individual components in isolation | Very Fast | Very Low |
Consumer-driven vs. provider-driven contracts#
Consumer-Driven Contracts — the consumer writes a contract specifying exactly what it needs; the provider runs tests to fulfill all consumer contracts (e.g. Pact). Pros: ensures the provider doesn't break existing consumers. Cons: complex to manage, requires a central Pact Broker, tightly couples the provider to consumer implementation details.
Provider-Driven Contracts (Schema-First) — the provider defines the contract using OpenAPI, the single source of truth. This is where CodeRifts fits in: it validates that any proposed changes are compatible with the existing contract, acting as an automated guardian of the provider's public interface. Pros: simpler workflow, single source of truth, enables automated tooling. Cons: requires discipline to keep the spec accurate.
Verified finding#
The contract verdict itself is signed (Ed25519). On the public demo pull request coderifts/demo#4 (2026-07-21), CodeRifts issued a deterministic BLOCK on 3 breaking changes and signed the verdict as a receipt (fingerprint sha256:70699341…cfec). Verify it yourself, offline — see Portable Verification.