Pagination

Several endpoints on the DriveWealth platform — including GET /accounts/{accountID}/transactions — paginate using a combination of limit, offset, and direction query parameters. This guide covers how to page through results correctly and efficiently.

Parameters

Response shape

The response is a plain array of results:

[
  {
    "accountAmount": 150,
    "accountBalance": 150,
    "accountType": "LIVE",
    "comment": "INSTANT_FUNDING - AFHF000003-1667569561072-DTKEP",
    "dnb": false,
    "finTranID": "JK.7534cf5c-cc4d-44e3-b5c0-5340a57b97af",
    "finTranTypeID": "JNLC",
    "feeSec": 0,
    "feeTaf": 0,
    "feeBase": 0,
    "feeXtraShares": 0,
    "feeExchange": 0,
    "fillQty": 0,
    "fillPx": 0,
    "sendCommissionToInteliclear": false,
    "systemAmount": 0,
    "tranAmount": 150,
    "tranSource": "INSTANT_FUNDING - AFHF000003-1667569561072-DTKEP",
    "tranWhen": "2022-11-05T13:00:05.671Z",
    "wlpAmount": 0,
    "wlpFinTranTypeID": "c43bab85-2916-4831-a0db-66215150a6e4"
  },
  {
    "accountAmount": -13.8,
    "accountBalance": 136.2,
    "accountType": "LIVE",
    "comment": "ALLOCATION master orderNo[JKTK004170], Buy  0.03633873 shares of IVV at 379.76",
    "dnb": false,
    "finTranID": "JK.de6a3be0-2510-4ab1-95f1-071caea310d7",
    "finTranTypeID": "SPUR",
    "feeSec": 0,
    "feeTaf": 0,
    "feeBase": 0,
    "feeXtraShares": 0,
    "feeExchange": 0,
    "fillQty": 0.03633873,
    "fillPx": 379.76,
    "instrument": {
      "id": "f6cb92cc-005b-4dfa-9d8b-2842e898072e",
      "symbol": "IVV",
      "name": "Core S&P 500 iShares ETF"
    },
    "orderID": "JK.1c044cf4-883e-46ae-8431-bcbf96099942",
    "orderNo": "JKQF003329",
    "sendCommissionToInteliclear": false,
    "systemAmount": 0,
    "tranAmount": -13.8,
    "tranSource": "MAM",
    "tranWhen": "2022-11-07T14:30:51.589Z",
    "wlpAmount": 0
  }

]

There is no pagination envelope — no hasMore, no total, no echoed offset. Pagination state is inferred entirely from the array you get back.

How offset actually works

Despite the name, offset is not "skip N rows." It's an ISO 8601 date — the same shape as from/to. To page forward: take the date value from the last transaction in your current page, and pass it back as offset with direction=next to get the following page. To page backward: use direction=prev with the earliest transaction's date instead.

Confirm which field on the transaction object holds this date before you build your paging loop — don't guess a field name into client code.

offset is also validated server-side: it must fall between from and to (inclusive), and it cannot be a future timestamp. Either violation returns a 400 error.

Example requests

First page:

curl -G "https://bo-api.drivewealth.net/back-office/accounts/{accountID}/transactions" \
  --data-urlencode "from=2026-01-01" \
  --data-urlencode "to=2026-03-31" \
  --data-urlencode "limit=1000" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "dw-client-app-key: $APP_KEY"

Next page — using a date value pulled from the last transaction of the previous response as offset:

curl -G "https://bo-api.drivewealth.net/back-office/accounts/{accountID}/transactions" \
  --data-urlencode "from=2026-01-01" \
  --data-urlencode "to=2026-03-31" \
  --data-urlencode "limit=1000" \
  --data-urlencode "offset=2026-02-14T18:32:07.000Z" \
  --data-urlencode "direction=next" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "dw-client-app-key: $APP_KEY"

Previous page — same offset, flip direction:

curl -G "https://bo-api.drivewealth.net/back-office/accounts/{accountID}/transactions" \
  --data-urlencode "from=2026-01-01" \
  --data-urlencode "to=2026-03-31" \
  --data-urlencode "limit=1000" \
  --data-urlencode "offset=2026-02-14T18:32:07.000Z" \
  --data-urlencode "direction=prev" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "dw-client-app-key: $APP_KEY"

Best practices

1. Keep from/to narrow. They're required on every call — use the tightest range your use case needs (a statement period, a tax year) rather than a whole account lifetime. A narrower range means fewer pages and a smaller payload per page.

2. Always set limit explicitly. No default or maximum is enforced, so there's no built-in ceiling protecting your client from an oversized response. Pick a sane value yourself (e.g. low hundreds to 1000 for an interactive UI, upto 5000 for batch/bulk), and if you find you need a larger page, narrow from/to instead of inflating limit.

3. Detect the end of results by page size, not by a flag. There is no hasMore field. Stop paging when the returned array is smaller than the limit you requested, or when it's empty. A full-size page doesn't guarantee more data — be ready for the next request to come back empty.

4. Never treat offset as a row count. It's a date boundary, not an index. Don't accumulate "rows seen so far" and pass that number in — it's the wrong type and isn't how the server interprets the parameter.

5. Page sequentially, one direction at a time. You only know the correct next offset after you've seen the previous page's data, so don't fetch multiple pages concurrently by guessing future date values — with no hasMore/total to reconcile against, gaps or overlaps from speculative paging can go undetected.

6. For bulk exports, chunk by date range, not by page count. If you're pulling a long history, split the work into multiple bounded from/to windows (e.g. per month or quarter) and page each window to completion, rather than one huge range plus many offset hops. This bounds the memory and retry cost of each chunk, and avoids relying on an unbounded limit. For bulk retrieval within a bounded date range, a limit of 5,000 is a reasonable value — high enough to minimize round trips, while leaving margin against oversized responses.

Anti-patterns to avoid

• ❌ Treating offset as a row-skip count (offset=100) — wrong type, not how this endpoint works.
• ❌ Omitting limit and trusting an implicit default — none exists.
• ❌ Requesting a huge from/to span with a huge limit "to get it all in one call" — there's no cap to stop an oversized response, and no pagination metadata to recover gracefully if it's too large.
• ❌ Assuming an empty array partway through paging is an error — it's the standard end-of-data signal for this pagination style.

A note on consistency

This limit/offset/direction pattern appears on a handful of endpoints in this API, but the exact semantics can vary by endpoint — for example, offset may be a date on one endpoint and an opaque token on another, and the direction enum values are not always identical. Always check the reference documentation for the specific endpoint you're integrating with rather than assuming behavior carries over from another endpoint that uses the same parameter names.