Cairn is going open source soon.Star the repo
API contract tracking

Catch breaking API drift before your users do.

Cairn fingerprints every API response your flows touch and watches for breaking contract drift — so it names the failing call behind a UI break, not just the red X.

Contract drift, caught

It learns every contract — and notices when one breaks.

Cairn fingerprints the API responses your flows touch, diffs each run against the last known-good shape, and names the exact field that drifted.

Contracts captured this run
GET/api/productsstable
GET/api/cartstable
POST/api/billing drift
fingerprinted from real traffic — no spec to write
POST /api/billingbaseline → this run
breakingstatus string → number · declineReason removed
→ issue filed naming the changed fields
The problem

When the contract changes, the UI breaks — confusingly.

Your frontend and backend agree on a contract: the shape of every API response. That agreement is invisible and unenforced — until a backend change renames a field or flips a type, and the UI quietly breaks in a way no one traces back to the API.

By the time it surfaces, it looks like a frontend bug. Someone debugs the component, the state, the rendering — everything except the response shape that actually changed.

Cairn watches the contract for you. It learns the shape of every response your flows touch, notices when one drifts in a breaking way, and names the field that changed — so the diagnosis points at the cause, not the symptom.

How it works

Learned from traffic, checked every run.

No contract to hand-write and no separate test suite — Cairn observes, fingerprints, and diffs the responses your flows already produce.

1

Records the browser's traffic

As your flows run, Cairn records the browser's network traffic and captures every API response your app returns — fingerprinting the shape, never the values. No contract to hand-write and no extra requests to make.

2

Fingerprints the shape

It normalizes each response into a structural fingerprint — the fields, their types, the nesting — that it can compare run over run.

3

Diffs against known-good

Each run's contract is compared against the last good one, and an OpenAPI snapshot if you have one. Additive changes quietly evolve the baseline; breaking ones are flagged.

4

Names the change and files it

When breaking drift shows up on a flow that failed, Cairn files an issue naming the endpoint and the exact fields that changed — and, with auto-fix enabled, can draft a fix PR.

Why it's different

The cause, not the symptom.

Contract drift usually shows up as a confusing UI bug. Cairn skips the wild-goose chase and points straight at what changed.

From real traffic, no spec

Contracts are learned passively from the requests your tests already make — there's nothing to write and nothing extra to run.

Names the exact field

Cairn doesn't just say 'the API changed' — it tells you which field changed type or disappeared, so you fix the contract directly.

Tied to the UI break

When drift breaks a flow, the issue connects the failing UI to the response that caused it — ending the frontend wild-goose chase.

Out of the box this covers your first-party contracts — the API routes your own app serves, captured from the browser's traffic. To extend it to the calls your backend makes to upstream and third-party services, add the open-source vela-cairn package and call register() once at startup; it fingerprints those server-side calls during test runs and reports their shape, never their data. First-party tracking needs no install.

Either way, contract tracking turns silent, downstream breakages into named, actionable changes — the same way root-cause issues turn a red test into a fixable report.

FAQ

Frequently asked questions

During every test run, Cairn records the browser's network traffic and fingerprints the shape of each API response — field names, types, and structure, never the values. There's no contract to hand-write and nothing to install for this.

On its own, it sees what the browser sees: your app's own API routes, Server Actions, and GraphQL — your first-party contracts. To also track the outbound calls your backend makes to upstream or third-party services, you add the open-source vela-cairn package and call register() once; it fingerprints those server-side calls during test runs. That coverage is additive — first-party tracking works with no install.

A change a client wouldn't expect: a field that changed type, a field that was removed, or a structural change to the payload. Additive changes are tracked and quietly evolve the baseline rather than raising an alarm.

No, but Cairn uses one if you have it. It diffs against the last known-good contract it observed from real traffic, and can use an OpenAPI snapshot as an additional reference point.

When a breaking contract change shows up on a flow that failed, Cairn files a GitHub issue naming the endpoint and the exact fields that changed — and, with auto-fix enabled, can draft a fix PR. Breaking drift on a still-passing flow is recorded in the dashboard rather than filed.

No. The first-party capture is passive — it reads the browser traffic your tests already generate. There are no extra requests and no separate contract-test suite to maintain.

Put your tests on autopilot.

Connect a repo and watch Cairn map your flows, write the tests, and run them on every PR — in minutes.