What’s Broken in API Tooling
API tooling looks mature, but the daily workflow still feels messy.
Not because sending a request is hard. curl solved that decades ago. The broken part is everything around the request: auth, environments, shared headers, chained calls, debugging, docs, tests, mocks, history, and collaboration.
Most API clients still treat requests like isolated forms.
Method - URL - Headers. - Body - Auth - Send.
That works for one endpoint. It breaks down when the work becomes a flow: log in, extract a token, create a resource, use its ID somewhere else, test an edge case, compare the response, document the behavior, and share it with someone else.
That is not a request. That is a workflow.
The bigger issue is that API work often lives as app state instead of project state.
Your code lives in Git. Your tests live in the repo. Your docs are Markdown. Your CI config is committed. But your API requests often live inside a separate workspace, synced through a separate cloud account, with history and environments trapped inside the tool.
That split creates drift. The docs say one thing. The spec says another. The tests cover something else. The “working request” lives in someone’s API client. The debugging context is buried in local history.
API requests are not disposable. They are project knowledge. They capture auth, payloads, headers, environments, response shapes, and assumptions about how the system behaves.
That knowledge should be easy to version, review, diff, reuse, and run again. This is where API tooling needs to change.
A few things to keep in mind :
- Requests should be file-first.
- Workflows should be composable.
- History should help with debugging.
- Docs, tests, mocks, and examples should live closer together.
- Collaboration should not require locking everything inside a vendor workspace.
A good API client should still have a great UI. Visual tools matter. But the source of truth should belong to the project, not the app.