Checking for changes
Polling for Response Changes
The response feeds endpoint allows developers to track changes to participant responses incrementally, rather than repeatedly fetching entire datasets. Each feed query returns a list of response events (created, updated, rejected, or deleted) along with a cursor that marks the current position in the change log.
Developers can:
Request a feed for a specific
testId
or across multiple tests.Use the returned cursor token to fetch only new events since the last poll.
Handle batched changes efficiently with predictable ordering.
Reduce load on clients and servers by avoiding full refreshes.
This makes it simple to keep a local data store, dashboard, or integration layer in sync with the latest state of responses.
Optimizing change detection with testResultChangesCount
For applications that poll frequently or need to minimize API calls, the testResultChangesCount
query provides a more performant way to check for changes before fetching detailed data.
Why use testResultChangesCount?
Instead of fetching all change events every time you poll, testResultChangesCount
returns:
count — The number of unique test results that have changed
latestCursor — The cursor of the most recent change
This allows you to:
Check if any changes exist without transferring full change data
Get the latest cursor to use in subsequent
testResultChanges
queriesSkip unnecessary API calls when no changes have occurred
Reduce bandwidth by only fetching detailed changes when needed
Query structure
With sinceCursor parameter
Check for changes since a specific cursor:
If no changes have occurred:
Finding new or updated responses
We offer a feed of response updates for a specific test that you can to keep track of responses that have been created, updated, rejected or deleted since your last check.
How it works
When you request the testResultChanges
query for the first time you will receive the full change history for a specific test.
Each change entry returns a cursor
- you should store this.
When you make subsequent requests you can pass the stored cursor as the sinceCursor
argument to receive back only changes that have occurred since your previous check.
Example query
Here we're going to select a UserTestNode
using its UUID. For an explanation of how to find a test's UUID, see Projects.
First request
Subsequent requests
Example response
Please note that responses are not available in the feed until they're finalised, at which point they'll be recorded as UPDATED
.
Change types
The changeType
field indicates what kind of change occurred:
UPDATED
— The response data was updated (this is the initial completion event)VIDEO_UPDATED
— The video recording was processed or updatedVIDEO_TRANSCRIPTION_UPDATED
— The transcript for the video was generated or updatedREJECTED
— The response was rejected (e.g., failed quality checks)