API DOCUMENTATION / PLAN A SAFE DATA SYNC
Plan a safe data sync
Use stable request scope, idempotent writes, and explicit restart behavior with changes.
Start with bounded pages
A jobs list request supports limit from 1 to 250, default 50. A cursor is bound to query scope and the current projection watermark. Store filter values and page size alongside your local progress.
Handle cursor invalidation
If a projection publication changes its watermark, a jobs cursor no longer continues the old page sequence. Restart the query from the first page and make local writes idempotent on combined job_id and posting identity. The cursor has no source-defined time expiry for a long-running export.
Use the changes feed
The changes route accepts a starting timestamp or resume cursor and returns event pages. Keep each completed resume cursor with your idempotent writes. Catalog and projection failures can still return 503.
Persist progress you own
Record the filters, cursor, watermark, last completed page, and processing outcome. If the cursor is rejected, restart and deduplicate rather than treating a failed continuation as a complete sync.
Test recovery cases
Exercise a repeated page, a cursor rejected after publication, a partially written batch, 429 with Retry-After, and 503 unavailability. Keep request accounting in mind: authenticated malformed or unavailable requests can consume an admitted request unit.
Continue in the reference
Check related request behavior before you build.
View route status and methods Discuss API requirements