API workspace documentation

Build and organize application programming interface (API) requests, collections, and folders; manage environments, variables, auth, and secrets; and test requests with human-readable results and repeatable validation paths. This is the same Workspace help guidance shown inside the signed-in app.

How it works

Use Workspace to create, save, send, organize, and review API requests. The primary loop is selecting the right workspace asset, editing request details, sending through governed execution, and preserving reusable evidence for humans and MCP clients. Use a request or folder's Description field to preserve why a workaround exists, not just what it does: when a request encodes a hard-won fix for a third-party API's quirk — a required body shape, a stale-state rejection, a fragile URL format — write the failure you observed, the exact fix, and how to tell success from failure apart in the Description, so the next person (or agent) who touches this request does not have to rediscover it from a stack trace. Import a Postman v2.1 collection to bring in descriptions your team already wrote in Postman, or write them directly in Get2Post going forward.

Choose the active workspace first, then open or create the request or folder that owns the API change you need to make.
Set the method, URL, headers, parameters, body, auth, scripts, and tests using the editor tabs that match the request type.
Use Clone Request from a saved request's action menu when you need a safe editable copy without carrying over execution history or direct secret values.
Before exporting a workspace, review the affected authentication paths; exports omit free-form authentication usernames and secret values from inline Custom-auth settings, other stored authentication material including dormant values retained after choosing None or Inherit, and Environment secret references, so reattach auth from Environment-scoped secrets after import and rotate credentials if an older unsafe export was shared.
Save the request before sending if you want the exact draft, auth posture, and test setup to remain reusable for later runs.
Send the request through the normal execution path, then inspect response, timing, diff, and diagnostics tabs instead of relying on the body alone.
Verify the request still opens from the explorer with the expected saved details and that the response or activity evidence matches what you just tested.
Record a scar: when you fix a workaround for a flaky third-party API, open the request's Description field and note the observed failure, the exact request shape that works, and how you'd know if the provider changed behavior again.

Watch a quick walkthrough

Create and save an API request

Create a REST request, set method and URL, add the needed details, save it, reopen it, and verify persisted request evidence.

55 sec

Safely test an API request

Use a safe fixture API, send the request through governed execution, review response diagnostics, and save the smoke-test evidence.

51 sec

Use environment variables

Create a workspace variable, reference it from a request, save the request, and verify bounded substitution without exposing secrets.

50 sec

Configure auth inheritance and overrides

Review workspace or folder auth, inherit shared credentials where possible, override only the narrower request, and verify the effective auth source.

52 sec

Organize requests into folders

Create folders around API or workflow boundaries, move requests into the right group, reopen them, and verify organization did not break execution.