Paging through data and bulk sync

Use pagination to read retained outreach data for an integration or custom agent. Pages read live data. They do not provide a snapshot.

Choose a page size

Page sizes depend on the tool:

Tools	Default	Maximum	If limit exceeds the maximum
Standard paged lists	20	100	Uses 100
get_enrollment_history, list_replies	20	100	Uses 100
list_agents, list_agent_sources, list_agent_prospects	20	100	Rejects the request
search_docs	5	20	Uses 20

Paged account tools reject limits below 1 and fractional limits with invalid_arguments. Tools such as account totals and tasks do not use cursor pages. Documentation search returns a limited result set without a cursor.

Follow the returned cursor

1. Make the first request without cursor.
2. Read items, nextCursor, and hasMore.
3. Pass nextCursor as cursor while hasMore is true.
4. Keep the same tool, account, target, and filters for each request.

An empty page can still have a cursor. Agent scans and reply reads stop at fixed read limits, even when filters match nothing. Continue when hasMore is true. For replies, budgetExhausted explains when a read limit stops the page.

Standard lists usually return newest records first, with record IDs resolving tied timestamps. Video lists use the video timestamp. Agent lists use record-ID order. Retained status history follows stored append order, oldest first. Replies follow source order within each prospect’s sequence progress. They do not form one chronological list across sources.

Restart after a cursor error

A malformed cursor returns invalid_cursor. Agent, history, and reply cursors also reject another tool, account, target, or filter set.

A deleted, changed, or unavailable cursor record can return stale_cursor. History and replies also check previously read evidence for changes.

Restart without a cursor after stale_cursor. Start a new traversal when you change filters. The server does not silently restart a failed traversal.

Live changes can affect later pages. Inserts, deletions, or changed ordering fields can cause records to repeat or disappear during a traversal. History can include appended status changes. Analysis can arrive after you read a page. Do not describe pages as an unchanged snapshot or a report at a fixed time.

Sync retained sequence progress

Call list_enrollments with includeDetails: true to read contact information and step progress together:

{ "limit": 100, "includeDetails": true }

Each item includes prospectInfo and stepProgress. You do not need a separate detail call for those fields. This reduces requests when you sync many prospects. Follow the rate limits.

Without sequenceId, the list includes retained progress across sequences, including deleted sequences. This keeps retained progress accessible after you delete a sequence. It does not promise complete reply history.

Use the history and reply tools for stored status changes and reply evidence. Finishing their pages does not remove collection gaps.

Interpret current counts

get_stats counts your prospects’ sequence runs by current status, plus a total. Counts include runs in deleted sequences. Status groups include active, paused, completed, queued, canceled, and messageReceived. The total includes waiting states, so the listed statuses may not add up to the total.

The messageReceived count measures prospects waiting for reply review now. It decreases when prospects leave that state. It does not count all replies ever received.

list_sequences returns counters for everyone on your team who used each sequence. Its step-state groups include active, done, paused, queued, and waiting.

Sequence counters and account counts measure different things. Deleted sequences do not appear in the sequence list. Use account counts for your current status totals. Neither measure establishes historical reply rates or unique-person totals.