API testing in Trq

Build an HTTP request, hit Send, and see the response — then turn it into a repeatable, asserted test.

Trq isn't only a browser and mobile recorder. The same studio is a full API client: a session whose target is api is a list of HTTP requests you build with a visual editor — method, URL, params, headers, auth, body — send once to see the real response, and chain together into a multi-request test case that runs on every merge.

It lives right next to your web and mobile tests. An API session is a .trq file in the same project folder, opens in the same explorer, runs from the same Run button, reports into the same dock panel, and replays from the same trq CLI in CI.

Why it's here

Most real end-to-end tests aren't purely UI. You need to seed a user through an API before a login flow, poll a job endpoint, or assert that the backend your UI just poked actually changed. Bolting on a separate API tool means a second config, a second runner, and a second report. Trq folds it into one:

• 🔌 No browser, no CORS. API requests run server-side from trq (Node fetch), so there are no cross-origin walls, no cookie theatre, and nothing to launch — a request fires in milliseconds.
• 🧩 One project, three targets. Web, mobile, and API sessions sit side by side in the same folder, share environments and variables, and run together in a suite.
• 🔗 Requests chain. Extract a value from one response into {{var.NAME}} and send it in the next request's URL, headers, or body — a login → create → verify sequence is three rows.
• ✓ Assertions, not code. Check status, a JSON path, a header, response time, the raw body, or validate the whole body against a JSON Schema — all declarative, checked after every Send.
• 🌱 Environments built in. Point the same requests at dev, staging, or prod by switching one dropdown; {{env.*}} values swap for the run.
• 📄 A shareable report. Every run fills a Summary tab with a verdict, stat cards, and a per-request table — and downloads as one self-contained HTML file, the same format as web and mobile runs.
• ⚙️ CI-ready. trq play my-api-case replays the whole case headlessly and exits non-zero on any failure — a ready-made merge gate.

How it compares

	A standalone API client	Trq API sessions
Where it lives	A separate app & collection	Same project as your web/mobile tests
Chaining	Scripts in a pre-request tab	Extract → {{var.*}}, no code
Assertions	A test-script sandbox	Declarative rows + JSON Schema
Environments	Per-tool config	Shared {{env.*}} across all targets
CI	A separate runner	The same trq CLI
Report	Tool-specific	The same shareable HTML

Core concepts

• API session — one .trq file whose target is api; holds an ordered list of HTTP requests. This is your test case.
• Request — a method + URL with params, headers, auth, and a body; each can extract values and carry its own assertions.
• Send — fire a single request now, while authoring, to see the live response.
• Run — replay every request in the session top-to-bottom as one case, passing variables along the chain.

Ready?

Build your first request — you'll go from an empty session to a sent request with a green assertion in about a minute.