API workspace

A collection of saved endpoints that works as documentation and as a test client, shared by everyone in your workspace. Each endpoint holds its method, path, parameters, headers, body and the response examples you have seen. Unlike a generic HTTP client, it is built on what Pipehero already has: your tunnels reach localhost, and MCP lets your AI agent keep the collection up to date.

Get started

1. Open APIs in the dashboard and create a collection, or choose Import to start from what you already have.
2. Add an environment (local, staging, prod or custom) with a base_url and any variables.
3. Pick an endpoint, choose the environment and press Send. Save the response as an example to document it.

From the desktop app

The desktop app has an APIs tab with the same collections. It sends the request straight from your computer, with no tunnel and no Pipehero server in between, so it reaches localhost and private addresses too, on every plan. It asks for the values of secret variables (they never leave the server, so they are only kept while the app is open), asks twice before writing to production, and can save the response as an example. Save from traffic lists a tunnel's captured requests and turns one into docs with a click.

Environments and variables

Paths, header values and JSON bodies can use {{name}} variables that resolve against the selected environment. Dynamic values are built in: {{$uuid}}, {{$timestamp}}, {{$timestampMs}} and {{$randomInt}}. If a variable is missing, nothing is sent and you get the list of what to define.

Mark a variable as a secret for tokens and keys. Secrets are encrypted at rest, never shown again after you save them, and removed by value from run history and from the tunnel live tail.

Running requests

• Local: the request goes out through your tunnel to the port your CLI is already forwarding to, so it needs a running pipehero start. It also shows up in the live tail.
• Staging and prod (Pro and Team): sent from Pipehero's servers to public URLs only. Private and internal addresses are refused, redirects are not followed, and requests are capped at 20 seconds, 1 MiB of response and 30 runs per minute per workspace. A write to a prod environment asks you to confirm.
• History: the last 20 runs of each endpoint are kept and shared with the workspace. Credentials in headers are stored as redacted.

Document from real traffic

Open a request in a tunnel's live tail and choose Save to API docs. Pipehero adds the response as an example of the endpoint that already covers that route, or creates the endpoint from the request. Credentials, signatures and cookies are replaced by variables, ids in the path become variables, and only JSON bodies are kept. A response you already saved is not added twice. Your AI agent can do the same with the save_captured_request tool.

Check drift

Docs go stale. Check drift compares the collection with the latest requests a tunnel captured (up to 200) and lists what real traffic shows that the docs don't. It is a Pro and Team feature.

• Routes nobody documented, with how often they were called and the statuses seen.
• Status codes that have no example.
• Fields in real responses that no example has, or that have another type.
• Query parameters and request body fields that aren't documented.
• Documented fields that never appear, once there is enough traffic to say so.

Requests you sent with Send and requests that got no answer are left out. For routes, status codes and fields, Add to docs saves the request that shows the difference as an example, the same way as saving from the live tail. Your agent can do it too: check_api_drift returns the findings, each with the request that shows it.

Scheduled monitors

Open an endpoint and add a monitor: Pipehero sends it to a staging, production or custom environment every 5 minutes to 24 hours and judges the answer. It is a Pro and Team feature.

• Healthy means any 2xx by default. You can require an exact status, a maximum latency, or text the response must contain.
• One failure is a blip. After two in a row you get an email (to the workspace owner, or the address you set), once per failing streak, and another when it recovers.
• Monitors on production only run GET and HEAD, so a check never writes to it. Local environments can't be monitored because the checks run from Pipehero's servers.
• Checks go through the same protections as cloud runs (public addresses only, secrets stay secret). They don't appear in the run history or use your runs-per-minute budget, and each monitor keeps its last 100 checks.

History and restore

Every real change to an endpoint is kept, with who made it and which fields it touched. A change made by your AI agent is labeled AI agent, with the start of the token it used, so you can tell it from a teammate's edit. Open History on an endpoint to see what changed, before and after, and Restore this version to put it back. Restoring is a new version, so you can undo it too. Available on every plan: the latest 50 changes per endpoint are kept, and examples aren't part of the history.

Comments

On a Team workspace, teammates can leave comments on an endpoint (up to 2000 characters, 200 per endpoint). Anyone can mark one Resolved or reopen it, so a comment works as a shared to-do, and only its author can delete it. If you leave Team, existing comments stay readable.

Review AI changes

On a Team workspace you can require approval for what your AI agents change. Open AI changes in the collection panel and turn on Require approval for AI changes. From then on, when an agent creates or edits an endpoint, saves an example, deletes something or imports a spec, nothing changes: the request waits for a teammate, with a line saying what it would do and the exact call one click away.

• Approve applies the agent's own call, once, and the history shows the agent as the author. Reject discards it, with a reason the agent can read.
• The agent is told the change is pending, and list_api_proposals shows it later what was decided.
• Reading, exporting, checking drift and running requests are never held. Up to 100 changes can wait at once.

Import and export

Choose Import, then drop a file or browse for it (or paste a cURL command). The format is detected for you.

• OpenAPI 3.x (JSON or YAML): endpoints, parameters, examples, servers as environments and 3.1 webhooks.
• Postman v2.x: folders, saved responses as examples and collection variables as an environment.
• cURL: paste a command, or use "Copy as cURL" from your browser or a provider's docs.
• Browser capture (HAR): in DevTools open the Network tab, filter to Fetch/XHR and choose "Save all as HAR". Ids in paths are grouped, so /users/1 and /users/2 become one endpoint with a {{user_id}} variable.

Credentials are never imported. A header that carries one keeps its name and gets a {{variable}} in place of the value, which you define per environment. To take a collection with you, export it as OpenAPI 3.1 or Postman.

Keep it current with your AI agent

The Pipehero MCP server has tools to list collections, read endpoints, update them by route, save examples, import a spec and run a request. Connect it once, then ask:

claude mcp add --transport http pipehero https://mcp.pipehero.app/mcp

The full tool list is in Debug webhooks with AI. The skill teaches your agent when to use them.

Plans

Every plan also has a cap of 50 examples per endpoint and 256 KB per body. When you reach a limit, what you have stays readable and editable; you just can't add more. Plans are per workspace, see pricing.