Skip to main content

if / else blocks

A condition guards one request. A block guards a group of them, with optional else and else if arms — so a case can branch on a response without being split into separate files.

An API request list showing an if block wrapping two requests, an else arm, and the end marker

Wrap some requests​

  1. Select the requests the condition should govern — click one, or Shift-click a range.
  2. Right-click and choose Wrap in an if / else…
  3. Build the condition and confirm.

An if marker, your requests indented beneath it, and an end marker. Requests between them are sent only when the condition holds; anything after end always runs.

Add the other arms​

Right-click the if marker:

Menu itemWhat it does
Edit condition…Change what this arm asks
Add elseA final arm, for when nothing above matched
Add else if…Another condition, tried in order, before any else
Remove the if / else (keep requests)Delete the markers; the requests stay, unguarded

:::caution Before 2.9.0 An else if arm never matched. Its condition was not evaluated, so the else arm always won instead. If you are on 2.8.3 or earlier, either update or use a nested if / else until you do — a plain if / else was never affected. :::

Arms are tried top to bottom and at most one runs. Once one matches, the rest are skipped without being evaluated.

Once an else exists, both Add else options switch off — an arm after the catch-all could never be reached.

What a condition can read​

The same four sources as a per-request condition:

SourceExample
Response statusstatus is 200
Response JSON pathdata.status equals complete
Response headerx-order-state equals shipped
A value or variable{{var.plan}} equals pro

A block's condition reads the response of the request before it — the same one a per-request condition on that position would see. See Conditions for the operator list.

What a run looks like​

Requests in an arm that didn't run are marked skipped rather than failed, and say which condition skipped them. They are not sent — no call leaves Trq.

Markers don't count as requests. A case with nine requests and two blocks still reports nine, and the if / else / end rows never appear in a report as passing or failing.

An example​

Only verify a payment when the order actually needs one:

1  POST /orders                     → 201
   if  response JSON  data.requiresPayment  equals  true
2    POST /payments
3    GET  /payments/{{var.paymentId}}
   else if  response status  equals  202
4    GET  /orders/{{var.orderId}}/queue
   else
5    GET  /orders/{{var.orderId}}
   end
6  POST /orders/{{var.orderId}}/confirm

Requests 1 and 6 always run. Exactly one of the three arms runs between them.

Nesting​

Blocks nest, and a block inside a skipped arm is never evaluated — its condition would be reading a response that was never fetched.

Half-authored blocks​

An if with no condition takes its else arm rather than guessing, so a marker you haven't finished never silently sends its requests. A stray end is ignored rather than failing the case.

See also​