CallListV3.make

Overview

When you need to retrieve all records from list methods of REST API version 3 with maximum efficiency and are ready to store the complete dataset in memory, use CallListV3.make().

This method automatically handles pagination and returns all data in a single array.

// Basic usage
const response = await $b24.actions.v3.callList.make({
  method: 'main.eventlog.list',
  params: {
    filter: [
      ['userId', '=', 1]
    ],
    select: ['id', 'userId']
  },
  idKey: 'id',
  customKeyForResult: 'items',
  requestId: 'unique-request-id',
  limit: 600
})

When to Use CallListV3.make()

1. Small to medium data volumes: When the total number of records does not exceed several thousand.
2. Simple processing: When you need simple access to all data at once.

Method Signature

make<T = unknown>(
  options: ActionCallListV3
): Promise<Result<T[]>>

Parameters

The options object contains the following properties:

Return Value

Promise<Result<T[]>> — a promise that resolves to a Result<T[]> object containing an array of all retrieved elements.

This object provides:

• .getData(): T[] — returns an array of all retrieved elements.
• .isSuccess: boolean — flag indicating successful execution of all requests.
• .getErrorMessages(): string[] — array of error messages.

Key Concepts

Performance Optimization

The method implements the Bitrix24 recommended algorithm for efficient work with large data volumes:

1. Filtering by increasing id: Each subsequent query uses a [cursorIdKey, '>', id] filter with the id of the last retrieved element (read via idKey).
2. Automatic data end detection: Requests stop when an empty array is received, or when a page is shorter than the largest page seen so far. This keys the stop on the page size the server actually returns rather than the requested options.limit, so a method that silently caps the page below limit (e.g. tasks.task.list, fixed at 50) still pages through every record instead of stopping after the first capped page. A short page ends the walk only once the cursor read from it has been checked — a page that is short and repeats the cursor is a server ignoring the page condition, not the end of the data, and is reported rather than returned.

REST API v3 Response Structure

In REST API version 3, various methods return data in the same structures:

• Grouped array: { result: { items: [...] } }

The customKeyForResult parameter allows you to specify the key where the data is located in the response.

Limitations

• Page size is per method, not a global 1000: limit states what you want; the method decides what it gives. Measured on an on-premise build, tasks.task.list returns 50 however much is asked, and nothing in the response says it was capped. The walker keys end-of-data on the largest page the server actually returned, so it pages through everything regardless — a hand-rolled loop on call.make does not.
• Sorting is fixed: The method always sorts by cursorIdKey (which defaults to idKey) ascending, because cursor pagination relies on [cursorIdKey, '>', nextId] filters to walk the dataset. A user-supplied order value would break that invariant, so the declared order property is Omitted from the type — though the [key: string]: unknown index signature it inherits means the compiler still accepts one — and any value passed at runtime is stripped with a warning log entry. To narrow the result set, use filter instead.
• filter must be the v3 array form: [['id', '>', 100]], or the output of FilterV3.build(...). The restApi:v2 object dialect ({ '>id': 100 }) is accepted by TypeCallParamsV3 for backward compatibility and works with a plain call, but not here: cursor pagination appends [cursorIdKey, '>', nextId] to the same filter on every page, so an array is the only shape it can extend. Passing an object throws SdkError with code JSSDK_ACTION_V3_LIST_FILTER_NOT_ARRAY. It used to be accepted and then failed mid-walk with filter is not iterable.
• A cursor that stops advancing is fatal: if the last idKey value on a page equals the one already filtered on, the >cursorIdKey condition was dropped and the same page will keep arriving. A full page cannot end the walk on its own — the largest-page-seen stop never fires — and a short one is checked before it is taken for the end of the data, so it throws SdkError with code JSSDK_ACTION_CURSOR_STALLED instead of collecting duplicates for ever. The usual cause is idKey naming the response field while cursorIdKey is left to default to it: tasks.task.list returns a lowercase id but filters on an uppercase ID, so it needs both (idKey: 'id', cursorIdKey: 'ID'). A cursor that moves the wrong way is caught too, and separately: a server alternating between two pages never repeats the value just sent, so the equality test above cannot see it — the walk is stopped with JSSDK_ACTION_CURSOR_WENT_BACKWARDS on the first backwards step. And neither check waits for a full page any more: a short page whose cursor did not advance used to end the walk as end-of-data, returning a truncated and overlapping result with no error at all.
• Only for list methods: Intended only for methods that return data arrays.

Error Handling

Always check the result using isSuccess and handle errors:

// @check-ignore: top-level return in error-handling illustration; some.method is a placeholder, not a portal method

const response = await $b24.actions.v3.callList.make({
  method: 'some.method',
  params: { /* some_params */ },
  idKey: 'id',
  customKeyForResult: 'items',
  requestId: 'unique-request-id',
  limit: 600
})

if (!response.isSuccess) {
  // Handling error
  console.error(new Error(`Error: ${response.getErrorMessages().join('; ')}`))
  return
}

// Working with a successful result
const data = response.getData()

Examples

Getting all Event Log Items with filtering

import { B24Hook, LoggerFactory, Text, SdkError, AjaxError } from '@bitrix24/b24jssdk'

type MainEventLogItem = {
  id: number
  userId: number
}

const devMode = !!(typeof import.meta !== 'undefined' && (import.meta.dev || import.meta.env?.DEV))
const $logger = LoggerFactory.createForBrowser('Example:AllMainEventLogItems', devMode)
const $b24 = B24Hook.fromWebhookUrl('https://your_domain.bitrix24.com/rest/1/webhook_code/')

async function getMainEventLogItemList(requestId: string): Promise<MainEventLogItem[]> {
  const sixMonthAgo = new Date()
  sixMonthAgo.setMonth((new Date()).getMonth() - 6)
  sixMonthAgo.setHours(0, 0, 0)

  const response = await $b24.actions.v3.callList.make<MainEventLogItem>({
    method: 'main.eventlog.list',
    params: {
      filter: [
        ['timestampX', '>=', Text.toB24Format(sixMonthAgo)] // created at least 6 months ago
      ],
      select: ['id', 'userId']
    },
    idKey: 'id',
    customKeyForResult: 'items',
    requestId,
    limit: 60
  })

  if (!response.isSuccess) {
    throw new SdkError({
      code: 'MY_APP_GET_PROBLEM',
      description: `Problem ${response.getErrorMessages().join('; ')}`,
      status: 404
    })
  }

  return response.getData() ?? []
}

// Usage
const requestId = 'some-main-event-log-item-list'
try {
  const list = await getMainEventLogItemList(requestId)
  $logger.info(`List [${list?.length}]`, { requestId, list })
} catch (error) {
  if (error instanceof AjaxError) {
    $logger.critical(error.message, { requestId, code: error.code })
  } else {
    $logger.alert('Problem', { requestId, error })
  }
}

When the request and response id fields differ

Some methods sort / filter by one field name but return another (for example an uppercase ID in the request vs a lowercase id in the payload). Set idKey to the response field and cursorIdKey to the request field:

// @check-ignore: some.list is a placeholder, not a portal method

const response = await $b24.actions.v3.callList.make({
  method: 'some.list',
  params: { select: ['ID', 'TITLE'] },
  idKey: 'id', // read the id from each returned item
  cursorIdKey: 'ID', // order + ["ID", ">", n] page filter in the request
  customKeyForResult: 'items'
})

The two ways of getting this wrong fail differently, and the difference matters:

• idKey cannot be read from a full page — you named a field the response does not carry. The SDK logs a warning and stops paginating rather than silently truncating; the Result holds what arrived so far, and it is real data.
• cursorIdKey names a field the server does not filter on — idKey reads fine, so the walk keeps going, but the page condition is dropped and the same page comes back for ever. That one throws SdkError with code JSSDK_ACTION_CURSOR_STALLED, because everything collected at that point is one page repeated.

Alternatives and Recommendations

• For working with lists: Instead of manually managing pagination use:
  • FetchList — returns an async generator for step-by-step processing of large lists.
• For batch operations: Use Batch to execute up to 50 commands in a single request.
• On the client-side (browser): Use the built-in B24Frame object.
• See also: Filtering — building the filter (and why order is stripped).

Bounding the walk

The walk pages until the data runs out. Three options bound it.

maxPages stops after that many pages and throws JSSDK_ACTION_MAX_PAGES_EXCEEDED, naming the method. The rows already read are not discarded — they come back with the error attached, so check isSuccess. It defaults to 10 000 — a backstop rather than a policy: on restApi:v3 that is 500 000 rows at the default page size of 50, and more only where the method's own cap allows a larger limit, and at the default drain rate of 2 requests/second roughly 83 minutes, so a walk that never ends is bounded without capping a read anyone performs. Raise it when a read genuinely needs more.

It errors rather than truncating. A short list that looks complete is the failure mode this whole class of bug keeps producing, so nothing is returned.

signal takes an AbortSignal and throws JSSDK_ACTION_ABORTED. It is checked at the top of each iteration, so an already-aborted signal costs no request at all.

progress is called after each collected page with { pages, rows }. Counts, not a percentage: cursor paging reads no total — restApi:v3 sends none, and on v2 the walk never asks for one — so a denominator would have to be invented.

// const $b24 = ...
const controller = new AbortController()

const response = await $b24.actions.v3.callList.make({
  method: 'main.eventlog.list',
  params: { select: ['id', 'severity'] },
  idKey: 'id',
  customKeyForResult: 'items',
  maxPages: 200,
  signal: controller.signal,
  progress: ({ pages, rows }) => console.log(`${pages} pages, ${rows} rows`)
})