Video tutorial of using loops
Loop Training
Mental model: loops are controlled by two actions
On the platform, a loop is effectively a pair:
Loop Through … (creates a loop context and emits a Loop ID + current index/item)
Continue Loop (decides “keep going” vs “exit” for that Loop ID)
Rule of thumb: every loop needs its own Continue Loop, and the Continue Loop must be wired back to the loop action so you can provide the Continue Loop ID to the loop config.
Pattern 1: Loop through a number range (pagination)
When to use
API pagination: pages 1..N
Any numeric range: retry counters, batch windows, index-based iteration
Example Pagination Structure
API call (page 1) to discover pages
Compare numbers:
pages > 1If yes: Loop Through Number Range
Inside loop: API call with
page = loop indexContinue Loop wired to the number range loop
Key configuration details
Start index: commonly
2if you already fetched page 1 outside the loopMax index:
pagesIncrement: defaults to
1if not set
Production readiness tip
Always connect the “No” branch (no loop required) to your “done” path. Otherwise a single-page response can leave your flow hanging or missing a terminal step.
Pattern 2: Loop through a JSON array
When to use
Response body contains an array of objects and you want to process each item
Examples:
docs[],items[],rows[], etc.
Structure
Loop Through a JSON Array
Inside loop: process item (log, transform, write to DB, call downstream API)
Continue Loop wired back to the array loop
The “fields to capture” lever
Instead of passing the full object downstream, you can extract only the fields you need (e.g., dialogue).
Why it matters:
Cleaner mappings
Less JSONPath (and fewer mistakes) in downstream actions
Faster iteration during debugging (you can log just the values you care about)
Safety lever: max items
For demos and debugging, set a Max number of items to avoid accidentally processing thousands of records.
Pattern 3: Two loops together (pages + docs)
Option A: Concurrent loops (speed first)
You can loop pages and trigger the per-page array loop in a way that results in multithreaded execution.
Use when:
You don’t care about processing order across pages
Throughput matters more than determinism
What to expect:
Interleaved outputs (“jumble”): page 2 items may appear before some page 1 items
Multiple “exit” events (the inner loop exits once per page)
Operational caution:
This can be fast, but it’s harder to debug because logs are not ordered by page.
Option B: Nested loops (order first)
Use a nested loop when you need:
All items from page 1 processed before page 2
All items from page 2 processed before page 3
Structure (high level)
Outer loop: Loop Through Number Range (pages)
Inside outer loop:
API call for that page
Inner loop: Loop Through a JSON Array (docs) for that page
After inner loop completes: Continue Loop (outer)
This produces deterministic, page-ordered processing.
Critical gotcha: Loop IDs in nested loops
Each Continue Loop needs the Loop ID for the loop it controls.
In nested loops:
Inner Continue Loop uses the inner loop’s Loop ID
Outer Continue Loop must use the outer loop’s Loop ID
What can go wrong
If you reuse the same Loop ID (or accidentally map the inner loop ID into the outer Continue Loop), the workflow can:
exit early
continue incorrectly
or behave unpredictably
The fix shown in the video:
Copy/store the outer loop ID from the outer loop action into a dedicated variable (e.g.,
outsideLoopId)Map
outsideLoopIdinto the outer Continue Loop action at the bottom of the nested structure
Another gotcha: overwritten outputs when reusing the same API call
If you call the same API action multiple times, fields like docs can get overwritten by the latest call.
A reliable approach:
Treat the first call as pages discovery only (don’t depend on its docs downstream), OR
Practical templates you can reuse
Template: Paginated API, order doesn’t matter (fast)
Get pages (page 1)
Loop pages 1..N concurrently
For each page: loop docs[] and process items
Best for: ingestion, analytics, best-effort processing
Template: Paginated API, order matters (deterministic)
Outer loop pages 1..N
For each page:
fetch page
inner loop docs[] and process
Continue outer loop only after inner finishes
Best for: sequential operations, rate-limited systems, workflows with dependencies
