Skip to main content
Four methods of the SDK return an iterator that walks a cursor list page by page. This page says how an iteration fetches, ends, stops and fails, how to page by hand when you need the cursor, and which list methods are not iterators. The filters, the order and the cursor rules of each list are in Pagination.

The four iterators

Each method returns an AsyncIterable. A for await loop receives the items one by one, and the SDK fetches the next page when the current one is consumed. No request is made before the loop starts.
Four rules apply to the iterators:
  • The filters go in the filters argument. The query option of a call is ignored on these four methods.
  • The filters argument does not accept cursor.
  • webhooks.events requires since.
  • messages.list yields the newest message first unless sort or order says otherwise.
Messages, chats and events carry handles and message text. Request them only when needed. Do not copy them into logs, tickets or other tools, and refer to a contact by an id of your own.

Page size

The page size is the limit filter, from 1 to 100. The SDK sends it with every page request and sets no default: the defaults of the API apply. The requests are made in sequence. Each page is one request. It counts against the request-rate limit, and a page of messages.list also counts against the message-operations limit: 60 requests per rolling 60 seconds for GET and POST /v1/messages together. See Rate limits. There is no total count.

End of an iteration

The iteration ends when the API reports has_more: false or returns no next_cursor.

Stop an iteration

break stops the iteration: no further page is fetched. A signal passed in the options also stops it. When the signal is aborted while your loop handles the items of a page, the loop still receives the rest of that page, then rejects with APIConnectionError (Pagination aborted) instead of requesting the next page. On the last page, it ends normally. When the signal is aborted before the response headers of a page arrive, that request is canceled, and the loop rejects with its APIConnectionError: see the messages of APIConnectionError.

Errors in a loop

An error on a page request is thrown from the loop, after the automatic retries of that request. The items already received stay processed. The SDK does not resume the iteration.

Page by hand

The iterators expose neither the cursor nor the page boundaries, and they do not accept a cursor. An interrupted iteration cannot be resumed through them. To keep the cursor, call the list operation with client.request. It resolves with one page, { items, has_more, next_cursor }:
A cursor does not expire. What a cursor is valid for differs between the lists: see Cursors.

Lists that are not iterators

These methods resolve with one page, or with the whole set: