For Google Drive apps that need to keep track of changes to files, polling repeatedly can be both inefficient and resource-intensive. The Changes feed provides a more efficient way to detect changes to all files, including those that have been shared with a user. The feed works by providing the current state of each file, if and only if the file has changed since the given changestamp.
A Change resource is uniquely and globally identified by a monotonically increasing integer identifier and represents a specific change to a user's file. Store the value of the latest change ID consumed by their application, and then query the API from that change ID in the future. This process is repeated over time to detect changes. This ensures an application never receives the same change twice from the API.
To retrieve the list of changes for the currently authenticated user, send a
GET request to the changes feed, as detailed in the List reference.
Entries in the changes feed are ordered in ascending chronological order. That is, the oldest changes show up first. The changes feed also contains a property named
largestChangeId to return the identifier of the latest change affecting the user. The same information is available in the About resource. The
includeSubscribed query parameters of the changes feed decide whether the response should include deleted and subscribed items, respectively.
The retrieved changes feed may or may not contain a
nextLink. If the
nextLink is present, it may be used to gather the next set of changes. If the
nextLink is not present, the client application should store the
largestChangeId in the feed for future use. With the largest change identifier stored, the client application is prepared to query again for changes in the future. The next time the application queries for changes, it should add the
pageToken query parameter to the URI, as in the following example:
[largestChangeId-plus-one] with the value of the latest stored change identifier, plus one. If the latest stored change identifier is 4351, then send 4352 here. This guarantees that in the next request to the feed, an application does not also receive a change received previously.