socket.help

API test scenarios

Save and reuse collections of integration test cases.

One repeatable check, from the first request to the last. Keep the setup, inspect every response, and share the scenario when it works.

Saving keeps request bodies and ordinary variables in this browser. Secret input values and run reports are never saved.

Request 1

Environment & secrets

Reusable setup, separate credentials
label

Secret values are sent only to this scenario’s base origin, through headers. They are excluded from saved scenarios and exports, and known values are redacted from the report.

2 sequential requestshttps://httpbin.org

Sends real HTTP requests from socket.help. Use a test endpoint you control or are authorized to test. Nothing runs on page load. A completed report uses one hosted run, including failed checks.

Import, export & API access

Imports configure the editor; they never run automatically. This version uses the socket.help scenario format rather than importing executable Postman scripts.

Use the scenario from curl
jq -Rs '{input: .}' api-scenario.json |
  curl https://socket.help/api/tools/mock-apis-api-test-scenarios/run -H 'Content-Type: application/json' --data-binary @-

# For a scenario without secret inputs:
socket-help run mock-apis-api-test-scenarios < api-scenario.json

# SDK: socket.run("mock-apis-api-test-scenarios", JSON.stringify(scenario))
# MCP: run_tool with the same toolId and input
# Supply declared secrets separately in options.secret as a JSON string.
Guide & examples

About API test scenarios

Build and run an ordered API request collection with environment variables, status and response checks, captured JSON fields and a per-request report.

When to use it

Repeat a small integration check without manually editing and sending every request.

API test scenarios example
GET /items → capture first ID → GET /items/{{itemId}} → check HTTP status and JSON fields

How to use it

  1. Configure one public base origin and up to six requests.
  2. Add checks and optional variables; supply secret values separately.
  3. Run once, inspect each result, then export the reusable scenario.

A small request collection you can repeat

Create up to six ordered requests against one public base origin. Give every request a name, method and relative path, then add its headers and optional body. The request list lets you move a step earlier or later without rewriting the collection. Every request has an expected HTTP status, and can also check a piece of text or the exact value of a JSON field.

The report separates passed, failed and skipped steps. Open a request to see its checks, response body, headers, byte count and measured duration. A server error can be the expected result: an intentional 404 passes when the expected status is 404. Disable Stop after a failed request or check when you want independent checks to continue.

Reuse variables without exporting credentials

Ordinary variables are named strings referenced as {{name}} in paths, headers and bodies. A request can capture a non-secret scalar JSON field, such as items.0.id, into a new variable for later steps. JSON paths use dotted object keys and array indexes; they do not evaluate JavaScript or a general query language. Put JSON body substitutions inside quoted strings so inserted characters can be escaped correctly.

Declare secrets separately and enter their values in masked fields. Only headers can reference those secret variables. Known values and sensitive response fields are redacted in the report. Secret input values are excluded from saved collections and JSON exports. Saving is explicit and local to this browser; ordinary bodies and variables are included, so review them before sharing an export.

Know what a run does

Pressing Run sends real requests from the socket.help server. All requests stay on the configured public origin, private and reserved addresses are blocked, redirects are returned without following them, and cookies are not replayed. Use test endpoints you control or are authorized to test. Cancellation stops pending work but cannot undo a request that has already reached the destination.

Each request has a three-second deadline and a 64 KiB response limit. A complete scenario has a twenty-second deadline and fits in 32 KiB. A completed report uses one hosted run, including failed assertions or request errors. Invalid configurations do not consume a run. The JSON scenario works through the HTTP API, SDK, CLI, SSH and platform MCP endpoint. This version does not run scripts, import Postman collections, schedule background tests or persist reports on the server.

Limits & privacy

Hosted sequential execution: up to six requests, three seconds per request and twenty seconds overall, 32 KiB scenario JSON, 8 KiB body templates and 64 KiB responses. All requests stay on one public origin; redirects and cookies are not followed or replayed. Secret variables are restricted to headers and excluded from exports. No scripts, background polling or retained execution history. A completed report uses one hosted run, including failed assertions or request errors; invalid configurations do not. Requests can change the destination service. Cancellation does not undo requests already sent.

Use this tool from the API reference or connect through the SDK, CLI, SSH, or MCP. Hosted calls share your plan allowances.

Read the full guide →