How to send requests in parallel in API Spector

A normal collection run sends requests one after another, on purpose: that is what lets a login request set a token the next request uses. But some bugs only show up when two requests arrive at the same moment. A classic case is a credit limit or stock count that two concurrent purchases both pass, because each read the balance before the other wrote it. To catch that, you need to send requests in parallel, and API Spector gives you two ways.

Fire requests at the same time in a flow

To send requests concurrently, use a Flow. Add a Parallel block, connect its branch output to each request you want fired at the same time, and connect its done output to whatever comes next. When the flow reaches the block, it sends all the connected requests at once and waits for them all to finish before continuing on done.

The block has a Copies setting, so a single connected request can be fired several times at once. That is how you reproduce the credit-limit race: point the block at the purchase request, set copies to a handful, and run the flow. If the responses come back a mix, say one 200 and one 409, or two that both should not have succeeded, you have found the race. Because it is a flow, the burst sits next to the setup that signs you in and the checks that look at what came back.

Run a whole collection or folder in parallel

The two options above are for firing specific requests at once. When you want a whole collection or folder to finish faster, the Runner has a Parallel setting next to Delay. Leave it at 1 for the normal sequential run, or raise it to run that many requests at the same time. The CLI takes the same control as --concurrency <n>:

api-spector run --workspace ./ws --concurrency 8

A parallel collection run is for independent requests, a batch of smoke tests or a data table with many rows, because it changes two things on purpose. Lifecycle hooks act as barriers: a Before All finishes before the batch starts and an After All runs after it ends, so setup and teardown still bracket the run. And each concurrent request starts from the same variable snapshot, so requests in the same batch do not see values that the others write while they run. That is why a chained sequence, where one request logs in and the next uses the token, should stay at concurrency 1.

Which to use

Use the Flow Parallel block to fire requests at the same moment, whether that is one request repeated with copies or several different requests together, and to reproduce a race. Use the Runner's Parallel setting (or --concurrency) to run a whole collection or folder of independent requests faster.

Why it helps

Concurrency bugs are hard to reproduce by hand, because you cannot click fast enough. Firing the requests together from a flow makes the race repeatable, and a mix of status codes turns "it sometimes double charges" into a result you can see and point at. And when the requests are independent, running the collection in parallel turns a long sequential run into a short one.