Launching today
Routebase
Catch API drift before your customers do
61 followers
Catch API drift before your customers do
61 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.
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.
@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.
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.
Really cool concept. One thing that would make this indispensable for my team is if Routebase could auto-generate a changelog or diff summary whenever a spec is updated, so we can quickly see what broke or changed without manually comparing versions.
@mzeyyenxgtv Thanks so much — glad it resonates! 🙌
Good news: this already exists. When you cut a new spec version, Routebase auto-generates a changelog from the diff against the previous version — added/removed/modified endpoints and schemas as clean Markdown. And every change is tagged breaking / non-breaking / deprecated with a migration hint, so "what broke" is answered for you. You can also diff any two versions on demand.
One choice: we generate it on publish rather than on every keystroke, to keep it meaningful. Would a live diff while editing a draft be useful for your team too? Happy to give you a walkthrough!
Adding a built-in code snippet generator per language/framework would be huge. Right now catching drift is great but if Routebase could also output a ready to paste fetch client for React, Python, Go etc. right from the spec tab it would save tons of time.
@selahattinjtpw Really appreciate this — and good news: a chunk of it already ships today. Every endpoint in Routebase gives you ready-to-paste request snippets in 8 flavors — JavaScript (fetch), Python, Go, cURL, HTTPie, C#, Java, Ruby — with an example body generated straight from the schema. You get them both in the spec editor and rendered inline in the published docs/playground, so it's a copy-click away.
Where you're pointing at something we don't have yet is the step up from a single-request snippet to a real client/SDK — one typed client over the whole spec (centralized base URL + auth, a method per operation), plus a proper React hook flavor rather than a bare fetch call. That's a genuinely useful gap and we're taking it into the backlog. Thanks for the nudge 🙏