Prospecting Search Exports: Verify the Complete Result Beyond the First Page

To verify a prospecting export, reconcile the unique delivered records against a precisely defined result set. Preserve the query, filters, count basis, snapshot or job identifier, pagination rules, and documented limits. A populated first page or downloaded file is not proof that every intended record was delivered.

Completeness is also different from accuracy. An export can contain every result from a poorly defined search, or contain correct records while omitting later pages. This guide focuses on delivery of the already-defined result set, not enrichment accuracy or the size of a vendor's database.

The worksheet below is a proposed acceptance check. No customer dataset, export result, or completeness percentage has been invented.

Preserve the query before comparing counts

Record the exact company or person criteria, selected object, search text, related-record conditions, sorting, and any enabled exclusions. Keep the saved query or list identifier alongside the written description. A plain-language summary can omit a condition that materially changes the result.

Unify's filter builder explains conditions and groups. Its list-building overview distinguishes lists from audiences: list membership changes through actions, while audience results follow saved conditions as data changes.

That distinction affects what “complete” means. A download from a changing audience must be tied to a specific evaluation time or supported snapshot. A download from a list must identify whether current search and filters narrow the exported membership.

Do not compare a company count to a people count. If the workflow moves from accounts to contacts, preserve that transition as a separate result set. The find and enrich target account contacts motion can help explain the workflow, but an account-to-contact transformation is not a pagination operation.

Identify the export surface and its documented limits

Different surfaces can have different limits and semantics. A chat table, a saved list, an API endpoint, and a query job should not inherit one another's behavior by assumption.

The build lists with chat guide documents the 50,000-row chat-table export limit. It also says the export follows current filters, search, and sorting. Do not apply that limit to every Unify API or list operation.

The Lists documentation says Download list exports the current search and filters, and advises clearing them when the whole list is intended. A correctly filtered export can be smaller than total membership without being truncated.

The query-jobs guide describes an asynchronous create, poll, and retrieve process. Its result pages have separate limits and availability rules. Evaluate the surface your integration actually uses.

Distinguish preview size from result-set size

Ask what the displayed count represents. It may be a total matched count, visible rows, selected rows, loaded records, or a count after exclusions. A vendor should identify the unit and timing rather than leave the evaluator to infer them from the interface.

Record any explicit cap. A disclosed limit can be planned around; a silent omission is a different problem. The acceptance decision should state whether the product delivers the whole intended set in one operation, requires partitioning, or cannot establish the complete result under the proposed workflow.

For chat-built lists, inspect save results separately from export results. Unify documents that saving new companies requires a usable domain and saving people requires an email address. Invalid or failed records, duplicate inputs, and records already in the list are reported separately from newly added members.

A table can therefore contain research results that do not all become newly saved list members. That is a record-creation or membership distinction, not necessarily an export failure. Keep the source table, save outcome, list membership, and downloaded file as separate evidence.

The company and contact data overview describes the prospecting data layer. It does not turn every preview into a guarantee of complete delivery. The specific interface and operation documentation remain the evidence for export behavior.

Follow query jobs through their full lifecycle

For a query-job workflow, retain the job ID and the request definition. Poll until the job reaches a terminal status. The documented states include IN_PROGRESS, FINISHED, FAILED, CANCELED, and EXPIRED. Only a finished job establishes that result pages are available for retrieval.

A FINISHED state does not mean the client downloaded every row. Inspect the total row count and retrieve the required pages. The record query results reference describes the result metadata and response behavior for object records.

Unify documents page-based result pagination with a stable ordering and tie-breaker for a finished job. JSON pages default to 1,000 rows and have a maximum of 2,000, with an 8 MiB raw payload limit. NDJSON supports up to 10,000 rows per page. These are format and page constraints, not a claim that the first page contains the whole result.

Jobs and results are available until expires_at, documented as 24 hours after job creation. Retrieve the required pages before expiration. If results expire, a new job is a new result snapshot; do not silently combine it with partial pages from the old job as though they necessarily describe one unchanged population.

The create record query job reference identifies the resource-specific request. Keep the exact filters and fields used. A generic query-job example for enrollments should not be copied as proof of the filters supported by company or person queries.

Handle failures and retries without inflating delivery

Unify documents query failures such as time limits, resource exhaustion, and internal errors. Failed jobs are not automatically retried; a new job is required. For resource or timeout problems, the guide recommends narrowing filters, selecting fewer attributes, or splitting the work into smaller jobs.

Treat a page retry as another attempt to retrieve the same records, not as new delivery. Store stable record IDs and deduplicate the client-side result before computing unique delivered counts. Preserve raw row counts as a separate diagnostic so repeated pages remain visible.

If a JSON page is too large, use a smaller page size or the documented NDJSON approach. Record the change and continue under the same finished job where supported. Do not respond to a page-size problem by dropping the remaining pages and reporting the partial file as complete.

Honor rate-limit responses and the documented Retry-After behavior. Use bounded concurrency and retain progress, rather than creating a new snapshot for every retry. This improves the ability to explain which records belong to which job.

If the export is partitioned into several queries, define non-overlapping boundaries or explicitly account for overlap. A set of files can each be complete while the combined delivery duplicates records or leaves a gap between partitions. Reconcile the union of stable IDs against the stated population.

Reconcile IDs, not only row totals

Two files can have the same number of rows and contain different records. Compare unique identifiers wherever the surface provides them. Record missing IDs, duplicate IDs, and IDs outside the intended result set as separate outcomes.

For a finished job with a documented total, compare the unique delivered IDs from all required pages against that job's total and, where available, the expected identifier set. A matching count is necessary for a count-based check but is not proof of identity-level equality when the expected set is unknown.

State that limit honestly. If you can establish only that all documented pages were retrieved and unique counts reconcile, call that a pagination-and-count reconciliation. Do not label it a full content-level proof of completeness unless the identities can also be compared to the intended set.

For list membership, use the relevant list-entry API reference and documented list access. The MCP tools reference describes another interface to list operations. An AI application's displayed summary may still be a preview, so inspect the underlying delivery behavior used by that application.

Keep filtering and exclusions visible during reconciliation. A record intentionally excluded from the defined set is not missing from the export. A record removed by an undocumented client-side filter is a different matter and should be investigated.

Use a query-to-delivery worksheet

The following worksheet is blank for an authorized evaluation. It contains no performed export or claimed success rate.

Attach the object type, selected fields, active filters, sort, job or list identifier, operation time, and any partition boundaries. Record the file or client artifact that was inspected and whether it represents all pages or only a subset.

For API workflows, add the page numbers or cursors processed, page sizes, response status, retry history, and final retrieval time. Keep those internal records free of unnecessary prospect details. The evaluation needs traceability, not a public copy of the dataset.

For UI exports, record the filters visible at download time and the resulting file's row and unique-record counts. If a limit requires several exports, document how the groups were defined and reconciled. Do not assume separate downloads automatically form a complete partition.

Define the completeness metric precisely

Choose the population as the unique records in the specified query snapshot or finished job. State the cutoff and the evidence for the expected set or total. The numerator for a delivery share is the unique expected records actually retrieved; the denominator is the expected unique population under the same definition.

Report unresolved identities, duplicate rows, unexpected records, failed pages, and intentionally excluded records separately. Do not remove a failed page from the denominator simply because its contents are unavailable. If the expected denominator cannot be established, report completeness as unverified rather than manufacturing a percentage.

When the expected set is empty, report not applicable and state that the query returned no expected records. A zero denominator is not a 100% accuracy claim. If the data changes during an unsnapshotted workflow, explain the comparability limit before reporting a single delivery rate.

No arithmetic example is needed to make this method useful. The important requirement is that another reviewer can reproduce the count basis and understand why a difference is either explained or unresolved.

Verify the handoff to the next workflow separately

A complete export does not establish that every delivered person is eligible for outreach. Before using it, inspect the relevant account eligibility and sequence exclusions. Completeness and permission are independent checks.

If the records are imported elsewhere, use the import-data guide for the corresponding operation and reconcile its results separately. Exported rows, successfully imported records, and newly added list members can differ for legitimate reasons.

The vendor decision should state the supported delivery path, explicit limits, evidence of full pagination, and any unresolved omissions. That is more actionable than a claim that the platform “has export,” especially when the buyer needs to operationalize a large, precisely defined target set.

Inspect partition boundaries before accepting a large export

When a result exceeds an explicit operation limit, define how smaller groups cover the intended set. The partitioning field should have a clear meaning and stable treatment of missing values. A group of records with no value for that field should not disappear merely because it fits none of the named partitions.

Record whether the groups overlap. Overlap can be intentional if the client reconciles stable IDs, but it must not inflate the unique delivered count. Gaps require a different correction: the missing range or category must be queried or explicitly excluded from the defined population.

Do not assume that splitting by a changing business attribute creates a stable snapshot. A record can move between groups while separate exports run. Where the workflow cannot freeze that condition, state the resulting uncertainty and use the documented snapshot or job mechanism when suitable.

Keep each partition's query definition and retrieval evidence. A combined file without those references can be hard to diagnose when a later reviewer finds a missing record. The objective is not merely to produce a larger file; it is to explain how the files together represent the defined search.

Review the downstream client's handling of pages

The vendor may expose complete paginated results while a client retrieves only the first page. Ask which component controls pagination in the actual workflow: the product UI, an integration, an AI application's tool call, or custom code. Locate the responsibility before attributing the omission to the data platform.

Inspect the documented continuation signal and the client's stopping condition. A client should not stop simply because a page looks sufficiently large or because a generated answer contains a plausible summary. It should follow the resource's documented result metadata and retain evidence of the pages processed.

For streaming output, verify that the client consumed the complete response and handled errors rather than accepting a partially written file as finished. A file existing on disk does not establish that the transfer completed. Preserve the relevant response or job status and the client's completion evidence.

Do not invent a guarantee that every third-party connector follows the same behavior. Evaluate the actual tool and configuration used by the team. A direct API test can help isolate the source of a discrepancy, but it does not automatically certify another client's implementation.

Record a bounded acceptance conclusion

Write the conclusion at the level supported by the evidence. The team may establish that every page of a specific finished job was retrieved, that unique counts reconcile, and that the expected IDs match. Alternatively, it may establish only the first two points because no independent expected-ID set exists.

Both conclusions can be useful when their limits are explicit. The weaker one should not be relabeled as full identity-level completeness, and an unresolved omission should not disappear into a rounded percentage.

State the export surface, limits, snapshot, and client reviewed. Identify who will revisit the check if the API, query, client, or partitioning method changes. This keeps a successful bounded review from becoming an unsupported permanent claim about every future export.

Frequently asked questions

Is a downloaded CSV proof that the whole search was exported?

No. Check the export surface, active filters, row limit, and intended result set. A file can be a valid partial or filtered result.

What is the documented Unify chat-table export limit?

The build-with-chat documentation states up to 50,000 rows per export, following current filters, search, and sorting. Do not apply that limit to every other Unify surface.

Does a FINISHED query job mean every result was downloaded?

No. It means results are available. The client must retrieve all required pages before expiration and reconcile unique records against the defined result set.

Can matching row counts prove identity-level completeness?

Not alone. Duplicate or unexpected records can mask missing ones. Compare stable IDs when possible and state when the evidence supports only pagination-and-count reconciliation.