Cursor-based pagination
Every response includes anext_cursor for fetching the next page:
Page size
Control the number of records per page with thelimit parameter:
Delta queries
Fetch only data that’s been ingested since your last sync usingingested_begin and ingested_end:
Time-based filtering
ingested_begin and ingested_end filter by when data was added to Emerge, not when the user performed the action. This is useful for incremental syncs.Response fields for delta sync
The response includes additional fields to help with delta syncing:Delta sync pattern
Best practices
Use applied_ingested_end for state
Use applied_ingested_end for state
Always use the
applied_ingested_end from the response as your next ingested_begin value. This ensures no gaps between syncs.Handle empty results
Handle empty results
An empty
data array with has_more: false means no new data since your last sync.Use reasonable page sizes
Use reasonable page sizes
500 records per page balances throughput and memory usage for most applications.
Implement backoff on errors
Implement backoff on errors
If you hit rate limits or errors, back off exponentially before retrying.
Deduplicate with event_id
Deduplicate with event_id
Each record includes an
event_id for deduplication. Use this to handle any potential duplicates across pagination boundaries.Async job pagination
For async queries, results are returned as a single Parquet file. The file contains all records for all users in the request. If you need to paginate through very large async results, use thebegin and end date parameters to narrow the time range: