A developer is building an incremental synchronization against the Dataverse Web API for the account table, which already has change tracking enabled. How should the first request and later requests be made so that each later run receives only the changes since the previous one?
Select an answer to reveal the explanation.
Short Explanation
You ask the Web API politely once: 'track changes for me, please,' with the Prefer header. It hands back a delta link, which is basically a bookmark URL. Next time you just follow the bookmark. Don't invent tokens or reuse ETags; those aren't how delta works.
Full Explanation
The Web API implements change tracking with OData delta links. The initial request includes the Prefer: odata.track-changes header, returns the current rows, and adds an @odata.deltaLink annotation whose URL contains a $deltatoken that the service generated. On the next run the client calls that delta link exactly as returned and receives created or updated rows, entries for deleted rows, and a new delta link to store for the following run. A $filter on modifiedon is a manual workaround that misses deletions, and $filter is not supported together with the track-changes preference. The $deltatoken value is opaque and issued by the service; a client cannot request a value such as latest. ETags with If-None-Match support optimistic concurrency and conditional retrieval of a single row; they do not produce a list of changes for a collection. Exam caveat: $orderby, $expand and $top are also unsupported with the track-changes preference, so select only the columns needed and page through results. Operational check: run the initial request, confirm the Preference-Applied header and the delta link, change one account, call the delta link and confirm only that account is returned with a new delta link.