Syncing a batch
When you append datapoints to a dataset, the datapoints land on the dataset — but a batch built from that dataset already has its tasks materialised from setup. A sync reconciles the two: it creates tasks for the datapoints added to the batch’s dataset since setup or the last sync, so participants can start annotating them.
This guide covers what a sync does, how to trigger one manually, how to poll its progress, and how to have syncs run automatically.
What a sync does
At setup, a batch turns every datapoint in its dataset into a task and organises those tasks into task groups. Appending adds datapoints to the dataset but leaves the batch’s tasks untouched. A sync closes that gap:
- It finds datapoints that don’t yet have a task in the batch (the delta since the last sync).
- It creates one task per new datapoint and slots them into task groups, following the batch’s existing grouping:
- Fixed-size grouping (
tasks_per_group): the open, partial group is topped up first, then any remaining datapoints are chunked into new groups. - Predetermined grouping (
task_group_idin the schema): datapoints join the existing group that carries their group key, or start a new keyed group.
- Fixed-size grouping (
- It updates the batch’s task and task-group counts.
Syncs are V4-only (the dataset must be a V4/schema dataset), and the batch must be READY — a batch that hasn’t been set up yet has no tasks to extend and must go through setup instead.
A sync only ever adds tasks for new datapoints. It never removes tasks, and no participant is assigned the same task group twice — including groups that grew during a sync.
Syncing manually
Trigger a sync with an empty POST. The batch’s attached dataset is synced.
The request returns 202 Accepted immediately with a sync job — the actual task creation happens asynchronously.
Keep the sync_id — you’ll use it to poll for completion.
The request is rejected with a 400 if the batch has no dataset attached, or if the batch isn’t in READY status.
Polling a sync
Poll the sync job with the batch_id and the sync_id from the trigger response.
Sync status
A complete job includes counts describing what the sync did:
If nothing has changed since the last sync, the job still completes — with all counts at 0.
A failed job carries a reason, for example when an import is in progress on the dataset while the sync runs:
Auto-sync
Rather than triggering a sync after every append, you can have a batch sync itself whenever datapoints are added to its dataset. Enable it by patching the batch:
With auto-sync on, every successful append to the dataset automatically enqueues a sync for the batch — no separate POST .../sync call needed. The append response returns as soon as the datapoints are written; the sync then runs asynchronously, exactly as a manual one does, and you can poll it the same way.
Enabling auto-sync on a batch that is already READY triggers an immediate catch-up sync, so any datapoints appended while it was off are materialised right away rather than waiting for the next append.
To turn it off, patch auto_sync_enabled back to false.
Recipe: append with auto-sync
Append datapoints: POST /datasets/{dataset_id}/datapoints. Check the accepted / rejected counts in the response.
Concurrency
Syncs for a single batch run one at a time — they’re serialised, so you never need to space out your requests. If a sync is already in flight when another is triggered (including an auto-sync fired by a fresh append), the in-flight active_sync on the batch record tells you so, and the redundant trigger is coalesced away. Because task creation is deterministic, retries and redeliveries converge on the same result rather than double-creating tasks.
By using AI Task Builder, you agree to our AI Task Builder Terms.