Hook
Most Domo APIs won't return more than 50 records at a time — and if your CodeEngine function only calls an endpoint once, you're silently missing data.
Why It Matters
Pagination is one of those problems that doesn't announce itself. Your function runs, returns results, and looks correct — until you realize you only got the first page. Without a reusable loop pattern, every API-backed CodeEngine function needs its own pagination logic bolted on. A well-designed looper abstraction means you write the pattern once, handle both common pagination styles, and never silently truncate results again. This is the foundational plumbing that makes CodeEngine viable for real production integrations against Domo's Groups, Users, Datasets, and similar paginated endpoints.
What You'll Learn
- Understand why Domo APIs return paginated results and what default limits look like
- Build a reusable
looperfunction that handles both URL query parameter and request body pagination styles - Configure
loop_configwithoffset,limit,maximum, andloop_until_endoptions - Distinguish when to pass pagination parameters as query params vs. POST body fields
- Chain the looper with the authentication pattern from Part 1 to make authenticated, paginated API calls
Building a Pagination-Aware Looper in CodeEngine
Jae walks through the Domo Groups API as the concrete example — it exposes limit=50 and offset=0 as URL query parameters, which is one of the two common pagination styles you'll encounter. The other passes those same values in the POST body. Rather than write two separate functions, the looper is designed to detect which style applies and route accordingly.
The function signature accepts the familiar authentication surface from Part 1 (account_name and access_token), then adds a loop_config dict that controls pagination behavior:
limit— how many records to pull per request (default typically 50)offset— starting row index, incremented automatically each loopmaximum— hard cap on total records fetched, useful for testing or rate-limit protectionloop_until_end— boolean override that ignoresmaximumand keeps fetching until the API returns an empty page
The key engineering decision here is separating where the pagination params live (URL vs. body) from the logic of iterating. Jae acknowledges a cleaner alternative would be two distinct functions (loop_params and loop_body), but consolidating into one with branching logic keeps the call surface smaller for downstream app integrations.
One practical callout: loop_until_end=False is the safe default. Flipping it to True without a maximum guard against a large dataset (or a misconfigured endpoint) can produce unexpectedly long-running functions — something worth surfacing in your CodeEngine timeout config.
This looper becomes the second building block — after authentication — toward calling Domo APIs from custom apps without rewriting boilerplate on every endpoint.
