Launching today
Routebase
Catch API drift before your customers do
94 followers
Catch API drift before your customers do
94 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.)
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 🙏
spent an afternoon hooking it up to our openapi spec and it actually caught two stale routes in our docs i didn't know were drifting. the MCP bit for our agents is genuinely handy too.
@ebrarieklitgfp This made my day — catching silently drifting docs against the real spec is the whole reason the OpenAPI sync exists. And the MCP integration being genuinely useful for your agents is exactly the bet we made. Would love to hear how it holds up as you connect more of your spec.
Would love to see a visual diff view for breaking changes before publishing the spec update, so we can quickly show backend and frontend teams what exactly shifted instead of just flagging drift.
@azizayerrm9y this one already ships — sounds like we just buried it 😅 the publish wizard's first step is exactly that: a color-coded side-by-side diff of your current vs. last-published version, breaking changes flagged red with migration hints and a suggested version bump, all before you confirm. separate from the drift flagging. curious whether it covers what you need once you try it!
love that it actually catches drift across mocks, tests, and docs instead of just generating them separately. the MCP piece is smart too, basically lets agents stay in sync without a ton of glue code.
@nerminaydao7wn exactly the distinction we care about — anyone can scaffold a mock, a test and a doc from a spec once, but they rot the moment the spec moves. keeping them honest against the source is the whole point. and yeah, MCP means your agents read the same source of truth we do, so there's no glue layer to babysit. thanks for getting what we're going for 🙏
Honestly the MCP angle is what got me, I hooked our docs up and it actually flagged two stale endpoints we had been ignoring for months. Kind of wish the publish step was faster but the drift catching alone makes it worth using.
@srazgencilswsc thank you, this means a lot 🙏 stoked the drift catching and MCP are landing for you.
A diff view inside the publishing step would be huge so I can see exactly which endpoint fields changed before pushing the update live. Right now it just says "drift detected" but I have to hunt to figure out what actually moved.
@didem2rjr you're right that it's harder to see than it should be. the field-level diff actually is in the publish step — which endpoint, which field, old vs new — but today it's tucked behind a "View Full Diff" click, and the "drift detected" notification you're seeing is way too bare (it should link you straight to what moved). surfacing the exact fields right where you first land is exactly where we're taking it. thanks for calling it out 🙏