Launching today
Routebase
Catch API drift before your customers do
99 followers
Catch API drift before your customers do
99 followers
Your API lives in your design tool, your docs, your mocks, your tests, your monitoring — and every copy drifts. Routebase makes them one living source: change the spec, publish, and it catches what drifted. (Your AI agents read the same source over MCP.)
Does the drift detection also run in the direction nobody announces? Publishing a spec change and firing contract tests covers the drift you know about, but the deploy that reshapes a response without anyone touching the spec is the copy I've watched drift first. Whether the monitoring side watches the live API continuously or needs a publish to wake it up would be my deciding question as a buyer.
@vollos Yes — that split is exactly the point, because publish-triggered contract tests only ever catch the drift you started yourself.
The unannounced direction is handled by Monitoring, not the spec pipeline. You bind a monitor to an endpoint and set schema validation to Warn or Strict. It then hits the live URL on an interval (as tight as every 30s), validates the actual response body against that endpoint's response schema, and raises a Schema Drift alert when the shape diverges — no publish, nobody touching the spec. The deploy that quietly reshapes a 200 is precisely what it's there to catch.
Two honest boundaries so you can decide cleanly:
It's opt-in per endpoint — a monitor with nothing bound only watches uptime/status/latency; the schema check turns on once you bind the endpoint and set the mode.
It diffs the response body against the JSON Schema on a successful check. Header contracts, request bodies, and undocumented new endpoints aren't part of that automatic diff today.
So the monitoring side watches continuously once armed — it doesn't wait for a publish to wake up.
@denny_riedl Continuously once armed is what I was hoping to hear, and listing the two boundaries unprompted did more for trust here than a feature list would have. Opt-in per endpoint reads like a fair trade, whoever binds the monitor knows which response shapes matter most.
@vollos Appreciate that — and honestly you phrased the opt-in rationale better than we do. If you end up pointing it at a live API, I'd love to hear which drift it catches first. Thanks for the sharp question.
@denny_riedl Take the phrasing, it was yours already, I only read it back.
the request/response drift coverage in this thread is thorough. one direction I didn't see covered: outbound webhooks. those break consumers just as often as REST responses do, but there's no request to inspect, just whatever payload you decide to send on an event. is webhook payload schema part of the same spec/drift pipeline, or is that a separate problem you're leaving to the consumer to validate on their end?
@galdayan Great question, and you've spotted a real gap. Today the answer is honest: outbound webhook/event payloads are not in the spec/drift pipeline yet. Everything — mocks, tests, docs, drift — is built on request/response operations parsed from OpenAPI paths; we don't currently ingest the 3.1 webhooks/callbacks object or AsyncAPI, so event payloads aren't modeled at all. That's not a deliberate "leave it to the consumer" stance — it's just an unmodeled surface. You've convinced me it belongs on the roadmap as its own coverage axis (model the event contract → same doc/mock/test/drift guarantees as REST). Thanks for pushing on it. 🙏
@denny_riedl fair, and honestly the honest "not modeled yet" answer is more useful to me than a hand-wavy "sure we cover that." good to hear it's landing as a real roadmap item and not just a one-off nice-to-have, thanks for digging into it.
Congrats on the launch! I've run into API drift multiple times, so the centralized API spec makes sense. I'm curious about the last mile: how does Routebase keep the spec aligned with the actual frontend and backend implementations? Can CI block incompatible changes, or does Routebase only detect drift after deployment?
@mateuszkonik
Thanks — drift is the exact itch we built this for. Routebase is spec-first: the OpenAPI spec is the contract, and mocks, docs, tests and monitors are all derived from it. That gives you two directions of alignment.
Against your spec history: on publish we diff against the last version and classify breaking changes — endpoint removed, field made required, response type changed. Any derived artifact that's now stale gets flagged with a one-click "sync from spec."
Against your running API: contract test suites hit your real endpoints and monitors validate live responses against the schema — that's how you catch the implementation drifting from the contract.
On CI — great point, and honestly the missing piece today. The breaking-change diff and contract tests are already available headlessly (MCP + REST), so you can gate a build on them, but there's no drop-in GitHub Action yet. We're putting a turnkey CI check on the roadmap right now and shipping it as soon as possible.
…that's how you catch the implementation drifting from the contract. We don't reverse-engineer your API from source, though — the spec stays the source of truth.
@denny_riedl thanks, the GH Action sounds like a welcome addition. Another useful feature could be migration tracking: when a field is replaced but temporarily retained for backwards compatibility, Routebase could flag it once no consumers are using it anymore, making it clear when it's safe to remove. Of course, it's hard to guarantee it for external APIs.
@mateuszkonik You've basically described the endgame of the deprecation lifecycle we already have: announce → grace period → sunset → retire, with a successor link and a migration guide.
The "auto-flag once no consumer uses it" part I'll be straight about: knowing that for real means seeing the traffic. We observe requests against our own mock server, but for a live or external API we're not in the request path — which is exactly the caveat you flagged. So real-consumer, field-level "safe to remove now" is an honest future piece, not something we do today. Genuinely useful input, though — thanks.
Congrats on the launch. Catching API drift early is valuable only if teams can triage it quickly. Do you show the exact contract change, affected route, sample failing request, and confidence level so developers can separate real breakage from noise?
@yaroslav_stelmakh Exactly the right lens — triage speed is the whole game. Here's the honest breakdown of what a drift item gives you today:
Affected route: yes — every drift finding is tied to the specific endpoint the monitor covers, so the route is explicit, not inferred.
Exact change: yes, structured per field — the JSON path of the field, the kind of change (missing field / type mismatch / unexpected extra field / format mismatch), and the expected type. So you see which field drifted and how, not just "something changed."
Sample: we capture the failing check's actual response — a body sample, status code, response headers, and timing — so you can eyeball the real payload that broke the contract. What we don't do yet is replay the outbound request for you; the request is defined by the monitor/environment config rather than snapshotted per check.
Confidence: we don't emit a numeric confidence score today. What we do is classify each deviation by severity — a missing required field or type mismatch is an error (real breakage), an unexpected extra field is a warning, a format nuance is info. That severity is what separates "page someone" from "noise," and it's what drives the alert threshold.
Fair to say the raw signal is structured and route-precise; the piece we're actively investing in is a tighter triage surface around it (a dedicated drift view rather than a dashboard card). Appreciate the sharp question.
honestly the drift detection part is what pulled me in, super useful. one thing though, it would be amazing if you could add some kind of slack or teams alert when drift actually gets caught in prod, so the right person gets pinged right away instead of someone having to go check the dashboard. would save a lot of "wait when did this break" moments.
@demettozkavevg Thank you! You're pointing right at something we're actively working on. The plumbing is there — live monitors already raise a dedicated "schema drift" alert into our notification pipeline, and alert policies can fire to a webhook, so a Slack/Teams incoming webhook can already catch it. What we still owe you is the polished part: first-class Slack/Teams alerts (nicely formatted, right person pinged) and drift that pages by default instead of just logging quietly. It's on the roadmap — really useful nudge. 🙏
@demettozkavevg Quick update before the day ends: this went from "on the roadmap" to an actual scoped ticket this afternoon — first-class Slack/Teams alerts wired into alert policies, so the right person gets pinged instead of a channel dump. Your comment tipped the scale 🙏
@denny_riedl Congrats on the launch! The always-on monitoring detail is interesting! I'm curious how it handles auth gated endpoints for that continuous check.. Does it need live credentials handed over to hit protected routes, or is monitoring scoped to public endpoints only?
@clement_avq Great question — and no, it's not limited to public endpoints.
Monitors reuse the same environment auth you've already configured for testing that API, so there's no separate handing-over of credentials. Basic, Bearer, API key, OAuth2 and JWT are all supported — for OAuth2 we refresh the token automatically at check time, so a monitor keeps hitting a protected route without you babysitting it.
On the credential side: secrets are stored field-encrypted (not plaintext), and you can also just reference secret environment variables ({{token}}) instead of pasting a raw value. So you get continuous checks on protected routes without exposing anything.
@denny_riedl That answers it, thanks! Quick follow-up: if a credential expires or gets rotated on our end, does the monitor surface that as a distinct "auth failure" alert, or would it look the same as a schema drift alert? Want to make sure we're not chasing a false drift when it's actually just a stale token!
@clement_avq Good instinct to want to separate those — and yes, they're structurally distinct signals.
Schema drift is only ever evaluated on a successful check (a 2xx response whose body deviates from the contract). An expired or rotated credential does the opposite: the request itself fails — you get a 401/403, or if it's OAuth2 and the token refresh fails, the check fails before it even hits the route. Either way it's recorded as a failed check and rolls up under downtime/error-rate, never drift.
So a stale token can't masquerade as a schema change — drift validation doesn't even run on a failed check. And the check detail shows the real status code (e.g. "expected 200, got 401") or the auth-resolution error message, so it's clear at a glance whether you're looking at an auth problem vs. an actual contract change.
One honest caveat: today a 401 surfaces under the availability/downtime side rather than its own dedicated "auth failure" category — that's on our list to make more explicit. But you won't be chasing a phantom drift when it's really just a stale credential.
@denny_riedl That level of detail in the check log is really what matters day to day! Good to hear a dedicated auth-failure bucket is on the list though.. Appreciate the thorough answers, thanks!
How do you handle versioning when an API spec changes? Like if v1 and v2 need to coexist, does Routebase track both or do you have to manage that separately in your tool?
@talhakhalidmtk Great question — coexisting versions is exactly what we built for.
Routebase tracks both. Each version gets its own isolated snapshot of endpoints, schemas and folders, so editing v2 never touches v1. On top of that:
Aliases — pin v1/stable to a semver like 1.4.2 so consumers don't chase exact numbers.
Consumer strategy — configure per spec how versions are exposed (URL path /v1/users, header, query param, or content negotiation); the mock server routes to the matching version and the docs portal generates samples to match.
Deprecation & sunset — mark v1 deprecated with a sunset date, and it emits the right headers + reminders so you can retire it gracefully.
Plus a diff between any two versions for an auto-generated changelog. All in one place — no juggling v1/v2 in a separate tool.