when agent attempted to pull seat-count data, the export API paged past the end and returned duplicates: sync failed

TL;DR

Paging past the end happens when the agent trusts a page count or a next link that the API keeps serving, or when offset paging over changing data re-reads rows. The defence is layered: stop on an empty or short page, respect the API's own end signal, and deduplicate the pulled set on the seat's stable id before anything downstream counts it.

when agent attempted to pull seat-count data, the export API paged past the end and returned duplicates: sync failed

Use this when

• Seat counts come out higher than the billing system shows
• The same seat records appear multiple times in one pull
• Sync totals vary run to run for unchanged data

Not for this skill when

• Customers genuinely hold duplicate seats across workspaces
• The API's total is wrong at the vendor and needs their fix

Steps

1. Log per-page row counts and the first and last seat id of each page for one pull. Verify: the page where repetition begins is visible
2. Compare the API's stated total (if any) with the pulled unique count. Verify: the inflation size is quantified
3. Fix the loop's end condition to the API's documented end signal plus an empty-page stop. Verify: a test pull terminates at the true end
4. Deduplicate on stable seat id before counting, and report the duplicate count per run. Verify: downstream counts use unique seats even if a future paging bug recurs
5. Reconcile the corrected seat count against billing and flag accounts still diverging. Verify: seat truth now agrees across systems or carries named exceptions

Variant phrasings

export API pages past end duplicates

A related phrasing for the same underlying problem.

seat count inflated by duplicate pages

A related phrasing for the same underlying problem.

pagination duplicates in sync

A related phrasing for the same underlying problem.

Compatibility: Compatibility: seat and user export APIs from product admin or billing systems consumed by sync jobs, current versions.

Why it happens

Counting is only as honest as the pull beneath it. End-condition bugs inflate quietly because duplicates look like growth. Per-page logging convicts the loop, and dedupe-on-id is the seatbelt that keeps any recurrence from reaching a renewal conversation.

Edge cases / pitfalls

• Offset paging over live data duplicates and skips simultaneously; cursor paging avoids both where offered.
• Dedupe must never merge seats that share an email but are legitimately licensed in two workspaces. The stable id, not the email, is the key.
• A duplicate count that suddenly rises is itself a useful alert on API behaviour changes. Trend it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NlP5WuD9JiV6tTSqpkbqLg