Know when a vendor API changed. Before support does.
Your payments vendor changed last Monday. Nobody told you.
Latency regimes shift, a 4xx subcode steps up, a field starts arriving null 15% of the time. Every one of those returns 200 OK, so your monitoring agrees nothing is wrong. Contract Drift runs changepoint detection on the calls you already make and names the vendor and the day.
Fourteen real series, one vendor deploy, detection computed live in your browser.
The problem
Status pages report outages. Vendors ship degradations.
Your product runs on other people’s APIs, and they deploy on their schedule without telling you. The failures that follow are not outages: a nested object stops being expanded, an optional field goes null, p95 doubles, a validation gets stricter. Nothing in your stack objects, because at the HTTP layer nothing is wrong. You find out when a customer describes the symptom back to you.
The insight
You already generate the evidence. Every call is a sample.
You do not need the vendor’s changelog to know the vendor changed, and you do not need their cooperation either. Every request you send produces a latency, a status, a payload size, and a set of populated fields. Aggregate those daily and you have a time series describing the vendor’s behaviour from the only vantage point that matters, which is yours. A contract break is a changepoint in that series. Y Combinator’s Self-Maintaining APIs request is about applying vendor changes automatically; this is the half that has to come first, because you cannot auto-apply a change nobody noticed.
CUSUM on day-over-day percentage changes for sustained regime shifts, Bayesian Online Changepoint Detection (Adams & MacKay 2007) for abrupt ones, and Benjamini-Hochberg FDR control across every vendor × endpoint × metric combination, so watching six vendors on ten signals each does not mean a false alarm every morning.
How it works
Four steps, no data science team
An OpenTelemetry HTTP client span, a proxy log, or a middleware hook. No vendor cooperation, no vendor SDK, no synthetic traffic you have to pay for.
Latency percentiles, status-code and subcode rates, timeout rate, response size, field presence and null rate, and enum cardinality per field, sliced by vendor and endpoint.
Every series runs through CUSUM and BOCD. What crosses is filtered by Benjamini-Hochberg across the whole run, so an alert that arrives has survived the count of everything else you tested.
The alert carries the changepoint date, the affected endpoint, the before and after distributions, and example responses on both sides of the line. That is a support ticket with evidence attached, not a question.
Who it is for
The engineer who owns the integration nobody else understands
Teams whose product breaks when a vendor changes: payments, KYC and identity, logistics, insurance quoting, anything routing real transactions through third parties. Usually 10 to 150 engineers with three to twenty critical integrations and one person who happens to remember how each one behaves.
Pricing
- –Full detection engine
- –30-day history
- –Slack alerts
- –Latency and status signals
- –Payload and field-level signals
- –Per-endpoint slices
- –Before and after response capture
- –12-month history
- –PagerDuty and webhooks
- –Self-hosted option
- –Schema diffing across captured responses
- –Custom signals per endpoint
- –SSO and audit log
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| Pact / contract testing | Consumer-driven contract tests that run in CI against a recorded provider. | Tests the contract you wrote down, against a mock, before deploy. It cannot see what the live vendor started doing yesterday, and nobody writes an assertion for a field going null 15% of the time. |
| Postman Monitors / Checkly | Scheduled synthetic API checks with assertions you author. | Assertions catch what you predicted. Every check is a threshold someone picked once, so the alert either fires constantly or never, and the sample is your synthetic traffic rather than your real traffic. |
| Datadog / New Relic APM | Traces and dashboards for outbound HTTP calls with threshold monitors. | The spans are there and the detection is not. A static latency threshold cannot tell a new regime from a busy Tuesday, and nothing in an APM looks inside the response body. |
| Statuspage and vendor changelogs | The vendor telling you what the vendor did. | Reports outages, on the vendor’s timeline, at the vendor’s discretion. Silent behaviour changes are the exact class of event it is designed not to report. |
The honest failure mode is statistical power. A vendor you call four hundred times a day gives daily aggregates noisy enough that only large shifts are detectable, so the product is sharp for high-volume integrations and vague for the long tail, which is where a lot of the surprise lives. The second failure mode is ownership. Detection produces a finding whose fix belongs to someone else’s company, and if the answer to every alert is a support ticket that goes nowhere, teams stop reading them. Both are addressable, and neither is addressed by better detection.
Market
Priced against one bad integration week
Any company with a payments, identity, or logistics dependency has already lost a week to a vendor change and can name it. Team tier at $450 a month is under a day of one engineer, and the buying decision is made the first time it happens again. Five thousand companies at that tier is $27M ARR, and the count grows with every product built on somebody else’s API, which is now most of them.