Running a batch
One press, every item at once across all your keys — with two switches that decide whether it storms ahead or takes its time.
In this article (5)
A batch is the normal way to use FlowArray: a list of items, one press of Run, every item worked at the same time across every key in your pool. Forty product shots take about as long as the slowest few, not forty times one.
Getting the items in
Three ways, all the same to the engine:
- Type them in the items grid (Simple view inline, Map view via Edit items on the batch card).
- Upload a sheet — batch import, up to 200 rows.
- Have something else post them — a trigger or the API.
Each row is one item, tracked independently: its own status, key, attempt count, latency and cost. One item failing does not spoil the batch, and you can re-run just the failures afterwards.
The two switches next to Run
- All at once / One at a time. All at once is the point of the product — it uses your whole pool in parallel. Choose one at a time when a provider is touchy, when you want to watch the first few results before committing to the rest, or when a downstream system cannot cope with bursts.
- Wait for all to finish / Continue as each finishes. This governs what a later step does when earlier items are still running: wait for the complete set (right when a step needs to see everything), or let each item flow onward the moment it is ready (right when items are independent and you want results early).
While it runs
Statuses move queued → running → done (or failed) per item, results appear as they land, and the run page shows a lane per key so you can see the parallelism actually happening. See the run monitor.
In Map view the canvas shows the work moving: the connection into and out of a step that is running lights up and its dashes march in the direction of travel, and the running card itself pulses. When the lines go quiet, nothing is in flight.
FlowArray holds items back rather than letting them become rate-limit errors, cools a key down when a provider asks it to, and steps aside a key that has hit its own daily allowance so the rest of the pool keeps serving. You do not have to tune anything for this.
What stops a batch
- A daily spend limit being reached — new steps stop with a "budget reached" message; items already in flight finish. This is deliberate: stopping is cheaper than discovering the number on an invoice.
- A genuine provider refusal (bad key, invalid request, content refused) — the item fails and is reported. It is not retried, because retrying a refusal just costs money.
- Everything transient — a 429, a timeout, a blip — is retried inside the run according to the step's retry setting, with the provider's own cooldown honoured where it sends one.
Costs before you press Run
Rehearse with the Data tab for $0, or run the whole thing in free test mode if you have no keys attached yet. For what the numbers mean afterwards, see what a run costs.