Synchronize Management API records

Build a local copy by reading every page of each required Management v1 collection. Later runs retrieve changes with updatedSince. This is a current-record feed, not an audit log of every intermediate change or a complete account export.

Before you start

Complete the Management quickstart. Choose the collections from the reference and obtain their required scopes. Store one timestamp checkpoint per account and collection.

Your destination must support upserts and deactivation or deletion by record ID. Keep timestamps and tombstone state even when hiding discarded records from your application.

1. Load the complete collection

1. Record the run's start time in UTC as a candidate checkpoint. Keep your worker's clock synchronized and use an overlap interval for later runs.
2. Query one collection with first: 100, after: null, and no updatedSince for the initial load.
3. Check HTTP and GraphQL errors before using a response.
4. Store every node. For tombstone: false, insert or update the local record. For tombstone: true, remove or deactivate the record while retaining its synchronization timestamp.
5. When hasNextPage is true, request the next page with its endCursor. Keep all other arguments unchanged.
6. After the final page has been stored successfully, persist the candidate checkpoint. On failure, leave the previous checkpoint unchanged.

Repeat separately for each collection. A credential must include the scope of every exported collection. Each collection needs its own pagination run.

2. Retrieve later changes

Use the same operation from the quickstart. Set updatedSince to the previous completed checkpoint minus your chosen overlap interval, and start with after: null:

{
  "first": 100,
  "after": null,
  "updatedSince": "2026-10-18T08:25:00Z"
}

This is the operation's variables object, not the complete HTTP body. Page through every result before advancing the checkpoint to this run's start time. Do not advance it to the last record's timestamp or the run's finish time: concurrent changes can otherwise be skipped. An empty completed run can also advance to its start time.

Choose overlap to cover expected clock skew and delayed visibility, and run periodic reconciliation for your integration's completeness requirements. Use filter.updatedBefore to bound a run when needed. The API has no snapshot token; pagination over a changing account is not a transactional snapshot.

3. Make storage and retries idempotent

For each account, collection, and id:

• Apply records with a newer updatedAt, including tombstones.
• Treat an identical version as a replay; do not create another record or repeat downstream side effects.
• Avoid overwriting a newer version with an older one from an overlapping or retried run.
• Apply a newer active version if a previously discarded record is restored.

Do not assume timestamps are unique across records. The server also orders by ID, which is why a timestamp alone cannot replace the cursor within a run.

4. Recover a failed run

Retry transient network and server errors with bounded backoff; for HTTP 429 respect Retry-After. Retry the same page while the run remains active. If you restart the run, begin with after: null and the previous completed timestamp minus overlap. Replaying already stored pages is safe when storage is idempotent.

A cursor is only for continuing the current collection run. Do not decode it, share it across collections, or save it as the next incremental run's checkpoint. If a cursor is invalid, restart from the timestamp rather than inventing another cursor.

Completeness limits

Tombstones cover discarded records returned by these collections. They are not a guarantee of a permanent deletion ledger. The feed does not expose every historical version, related-record changes, or a database backup. Export child collections independently: a changed payment or attendance does not guarantee a changed parent order timestamp. Records without discard support always return tombstone: false; reconcile complete ID sets to detect hard deletions. Preserve timestamp microseconds when comparing versions. Use Query account data and reports to plan a broader integration.