Skip to main content

Loop Training

In this article you will learn the basics of using loops at Wrk

Wrk Product avatar
Written by Wrk Product
Updated over a week ago

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

  1. API call (page 1) to discover pages

  2. Compare numbers: pages > 1

  3. If yes: Loop Through Number Range

  4. Inside loop: API call with page = loop index

  5. Continue Loop wired to the number range loop

Key configuration details

  • Start index: commonly 2 if you already fetched page 1 outside the loop

  • Max index: pages

  • Increment: defaults to 1 if 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

  1. Loop Through a JSON Array

  2. Inside loop: process item (log, transform, write to DB, call downstream API)

  3. 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:

  1. API call for that page

  2. Inner loop: Loop Through a JSON Array (docs) for that page

  3. 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 outsideLoopId into 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

Did this answer your question?