Pagination¶

Every list endpoint in the GIB API (getTransactions, getBatches, getSubclients, and the rest) pages its results the same way: a limit and an offset query parameter, and a response that wraps the page in a shared envelope:

{
  "items": [],
  "limit": 100,
  "offset": 0,
  "total": 200
}

Defaults and maximums¶

limit defaults and maximums vary by endpoint family:

For any endpoint not listed here, check the operation's limit parameter in the API reference.

A limit above the maximum is rejected, not clamped: the request fails with a 400 BusinessError and a message like The limit should not exceed 1000. Please use pagination for more efficient execution (see Errors for the response shape). Omitting limit, or passing 0, gets you the default.

Walking a full list¶

The snippet below uses the same BASE_API_URL, API_KEY, and headers conventions as the guides. Request the endpoint's maximum and stop when a page comes back shorter than your limit:

url = f"{BASE_API_URL}/transaction"

def all_transactions(**filters):
    limit, offset = 1000, 0
    while True:
        params = {**filters, "limit": limit, "offset": offset}
        response = requests.request("GET", url, params=params, headers=headers)
        response.raise_for_status()
        page = response.json()
        yield from page["items"]
        if len(page["items"]) < limit:
            return
        offset += limit

The short-page check keeps working even while records are being created or deleted mid-walk. Treat total as a progress indicator rather than a loop bound.

Consistency while paging¶

There is no sort parameter; each endpoint's order is fixed, newest records first (getTransactions returns the newest batch first, getBatches and getSubclients descend by id). Offset pagination reads the live table: with newest-first ordering, records created between your page requests push existing rows deeper, so a long walk can see a record twice, and deletions can make it skip one.

Two ways to keep a long walk stable:

• Pin the window with date filters (create_date_from and create_date_to): new records land outside the window instead of shifting your pages.
• For bulk pulls (reconciliation, backfills, audits), prefer a filtered export over a long page walk: exportTransactions returns the same data as files in one request.

Practical guidance¶

• Use the endpoint's maximum limit for bulk walks and the default for interactive views.
• Always pass explicit date or state filters when you page; unfiltered walks get slower as your history grows.
• Rate limits apply per source IP (see Security → Rate limits); a full-history walk at limit=1000 stays far below the threshold.

Related concepts¶

• Errors, the shared error envelope for a rejected limit
• Security → Rate limits, the WAF threshold a paging loop consumes
• Transactions, the most-paged list in most integrations