To sync efficiently, fetch only the records that changed since your last run rather than
re-paging the entire collection every time.
updated_since
Pass updated_since — an ISO-8601 timestamp with an offset (a Z or numeric offset,
e.g. 2026-05-01T18:22:10Z). It returns records with updated_at at or after that time:
updated_since composes with the cursor — page through the filtered results exactly
as on the Pagination page, just with updated_since added to each request.
A malformed or offset-less updated_since (for example 2026-05-01 or
2026-05-01T18:22:10 with no Z) returns 400 (invalid_request).
A durable sync loop
Because results are ordered by updated_at ascending, a robust sync stores the
updated_at of the last item it processed and passes it as updated_since on the next
run:
updated_since is inclusive, so re-running with a stored watermark may re-return the
last record you already saw. Make your write idempotent (upsert by uuid) so replays
are harmless.
Transcripts change after ingestion
A meeting’s updated_at also moves when its transcript artifact is rebuilt, which happens
after ingestion rather than during it: usually because speakers on the transcript were
identified later, so lines that published null for speaker_name and speaker_role now
carry a name and a role. The utterances themselves are unchanged. When a meeting you have
already stored comes back in an updated_since page, re-fetch
GET /v1/meetings/{uuid}/transcript and compare its generated_at
with the value you recorded: a newer one means the JSONL behind the presigned URL has been
replaced, and is worth downloading again. 
