When I start integrating a new API, I do not want the first hour to be setup.
I usually want to answer a simpler question first:
how does this workflow actually behave?
That sounds obvious, but most API exploration still starts with a lot of prep:
create an account
find or generate credentials
set local environment variables
copy a curl command
send one request
copy an ID from the response
paste it into the next request
check the provider dashboard
repeat
That is fine when you already know the API.
It is slow when you are still trying to understand the integration.
The first thing I want is the workflow
When I evaluate an API, the first request is rarely the full story.
I want to know:
- what should I create?
- what comes back?
- which ID matters?
- what state changes after the request?
- what webhook or follow-up event should I expect?
- how do I know the workflow is actually complete?
Postman or curl can tell me whether one request returned 200.
But real integration work usually looks more like:
choose API
run workflow
inspect response
follow state
verify final result
That is the part I want to make runnable before setup.
What I am building
I am working on FetchSandbox MCP so developers can explore API workflows from their IDE.
The goal is simple:
choose an API
ask Cursor or Claude to run the workflow
see the verified result
No local env first.
No mock server stitching first.
No copy-pasting IDs between five tabs just to understand the happy path.
This is not meant to replace the real provider environment. Before shipping, you still need real credentials, real limits, production auth, webhook endpoints, monitoring, and all the normal engineering work.
But before that, developers should be able to explore the workflow quickly.
Especially now that coding agents are helping write integration code.
Docs tell the agent what should happen.
Runnable workflows let the agent prove what happened.
That is the gap I keep seeing with APIs.
The setup matters.
But the workflow should come first.
Top comments (0)