Use delta tokens for recurring synchronization

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

You have an indexed candidate list and want recurring change synchronization. The teaching API issues t1 after a complete initial snapshot; incremental responses contain stable-ID upsert/delete events and a final next_sync_token. Fields and short IDs are teaching conventions, not actual Ashby or SharePoint request formats.

Mechanism

Complete the initial snapshot and persist the server-issued token. Pass it unchanged on the next read, following actual pagination and event semantics. Apply updates by ID and delete only on explicit deletion events. Advance to the final token after all changes are applied. Keep the old checkpoint on failure and support safe replay by ID. Recover expired tokens through the service’s documented snapshot contract.

Bad example

Download one candidate page daily and replace the entire index. Delete every ID absent from that page and save the latest token before all pages are processed.

Good example

Follow the supplied teaching delta contract. Current token is t1; events are upsert c1 and delete c2; final next_sync_token is t2. Pass t1 unchanged and process every required page. Apply events by ID without interpreting absence as deletion. Save t2 only after successful application. On failure retain t1 and report processed scope/replay behavior. Recover invalid tokens under the service contract instead of inventing one.

Why the change matters

An ordinary list omission may reflect paging, permissions or filtering rather than deletion. Explicit events and continuation boundaries resolve that ambiguity. Advancing after application prevents a checkpoint from skipping unprocessed changes.

Observable expectation

For local c1,c2,c3, the fixture updates c1, deletes c2 and preserves c3, then saves t2. A failed c1 update retains t1 and reports failure, even though t2 was received.

Inspect completed pagination, event IDs and checkpoint order. These are teaching deductions without a live recruiting-service call.

Limits

Token meaning, pagination, deletion and expiry differ by service; follow its documentation. The method needs incremental support and transactional or replay-safe updates. Source instances support token reuse; this fixture’s wire fields and recovery rules are explicit teaching choices.