3.1 Visual API Testing & Chained Request Workflows

How to compose chained HTTP requests, pass auth headers, and validate status codes visually.

Testing an Integration, Not Just an Endpoint

Most real API bugs don’t live inside a single endpoint – they live in the handoff between requests: an auth token that expires between call one and call five, an order id from a create response that never quite makes it into the confirm request, a header that’s set on the happy path but forgotten on the retry. A tool that only fires one request at a time and checks its response in isolation, the way a lot of ad-hoc curl scripts and Postman smoke checks do, structurally can’t catch that class of bug. CertiQA’s API surface is built the opposite way: an API test case is an ordered sequence of API Request steps on the same canvas every other test type uses, and each step can read variables the ones before it produced.

Each request is an API Request step (action API_REQUEST under the hood) with its own seven-tab configuration panel: Params for query-string key/value pairs, Headers, Auth (None, Bearer token, Basic, an API key header, or a Vault secret picked from a dropdown instead of typed by hand), Body, Assertions, Vars, and Response & Results. You don’t have to fill all of them by hand, either – paste a raw curl command into the endpoint field or use the native Import cURL dialog, and CertiQA parses it into method, headers, auth, query params, and body automatically.

Live Request Execution & In-Modal Testing

You do not have to save, exit, and trigger a full test run just to verify whether an API step works. Clicking “⚡ Send” in the endpoint bar executes the request immediately against the target server (interpolating variables, appending params, and attaching auth credentials). The “Response & Results” tab opens automatically with the real HTTP status badge, round-trip latency in milliseconds, payload size, response headers table, and formatted JSON response body with one-click clipboard copy.

Crucially, live execution automatically runs every configured assertion rule against the actual response. You see instant visual indicators (✅ PASSED or ❌ FAILED) comparing actual vs expected values (e.g. status code 200, latency < 500ms, $.status == “success”) before committing the step.

Bidirectional cURL Interoperability

CertiQA provides complete cURL import and export directly in the step editor: click “Import cURL” to paste any raw curl snippet copied from Chrome DevTools, Postman, or API documentation. The parser automatically extracts the HTTP method (-X), URL, query parameters, headers (-H), Basic or Bearer authentication (-u, Authorization), and JSON/raw request bodies (-d, –data). Conversely, clicking “Copy cURL” generates an executable, cleanly formatted curl command from your configured step straight to your clipboard for quick terminal verification.

Chaining Requests With Variables

A login step’s Vars tab can capture a token from the response (say, into {{ accessToken }}); the very next step’s Auth tab, set to Bearer, references {{ accessToken }} and the platform resolves it at run time before the request goes out. Extend that pattern across a case – log in, create an order, fetch the order by id, cancel it – and you’re testing the same sequence a real client actually performs, not four endpoints that happen to sit in the same test file.

GraphQL Is Just Another Body Type

GraphQL doesn’t get a separate step type. The Body tab’s type selector includes GRAPHQL alongside JSON, XML, form-encoded, and raw text; picking it swaps in two dedicated editors – one for the query/mutation document, one for its variables object – so you’re not hand-escaping a multi-line GraphQL query into a single JSON string the way you would if GraphQL were forced through the generic JSON body path.

Config Tab	What It Holds
Params / Headers	Query-string parameters and request headers, each individually toggled on/off without deleting the row.
Auth	None, Bearer, Basic, an API-key header, or a Vault secret referenced directly rather than pasted in.
Body	JSON, XML, form-encoded, raw text, or GraphQL (query + variables editors).
Assertions	Structured checks on status, headers, latency, or the response body – see 3.2.
Vars	Values captured out of this response for later steps to reference – see 3.2.
Response & Results	Live in-modal response viewer, latency timing, status badge, and real-time assertion evaluations.

• 🔍 JSONPath Extractions & Assertions — How the Assertions and Vars tabs introduced above actually work, with the full target/operator vocabulary.