Test one pagination boundary before trusting a sync count
Format: Explainer.
A successful first page is not a complete sync. Pagination means a provider returns records in separate batches, so the connector must know whether more remain.
Microsoft Graph says to follow each @odata.nextLink until it no longer returns one to read all results.[11] This link points to the next batch. Other providers may use a different rule for getting the rest of the records.
Use this hypothetical fixture, or fixed set of test data, with your builder. It is invented, not a reply from a real API:
| Test page | Record IDs | More work? |
|---|---|---|
| First | R-A, R-B, R-C | Continue to the next test page |
| Second | R-D, R-E | End of fixture |
The expected unique set contains five records. Check the IDs as well as the count. A result containing a duplicate and a missing ID can look complete if you count only rows.
Now make the second test page fail. The tool should say “incomplete.” It should keep the last good page and a work ID to use when trying again. It should not say “three records synced” as though the source held only three.
Use this test line: records requested; expected IDs; received IDs; next page reached; failure shown; result after retry. Keep the same filters and access rights throughout the test. That way, a change in access will not hide a missing page.
For live data, ask what happens if someone adds or removes a record while the tool reads the pages. This small test checks the move between pages. It does not prove that a changing list will always arrive intact.
Book a Demo with Core Agentic to discuss completeness checks for a custom integration before a partial list becomes an operating decision.
Sources
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.