對於大多數應用程式情境而言，讓用戶端與 Gmail 保持同步非常重要。整體同步處理情境有兩種：完整同步處理和部分同步處理。您的用戶端首次連線至 Gmail 時，在其他極少數情況下，都需要完全同步處理。如果您的用戶端最近已完成同步處理，部分同步處理會是更輕量的替代方案，可取代完整同步。您也可以使用推播通知，即時觸發部分同步處理作業，只在必要時觸發，以免產生不必要的輪詢。
目錄
完整同步處理
如果您的應用程式第一次連線至 Gmail，或者如果無法進行部分同步，您就必須執行完整同步處理。在完整同步處理作業中，應用程式應根據您的用途，擷取並儲存最新訊息或執行緒。舉例來說，如果應用程式會顯示最近訊息的清單，您可能會想要擷取及快取足夠的訊息，以便支援回應式介面，前提是使用者捲動畫面超出前幾則訊息。執行完整同步作業的一般程序如下：
- 呼叫
messages.list以擷取訊息 ID 的第一頁。 - 為清單要求傳回的每則訊息，建立
messages.get要求的批次要求。如果應用程式顯示訊息內容，則在應用程式第一次擷取訊息並快取結果時，應使用format=FULL或format=RAW，以避免額外的擷取作業。如要擷取先前快取的訊息，建議使用format=MINIMAL減少回應的大小，因為只有labelIds可能會變更。 - 將更新內容合併到快取結果中。應用程式應儲存最新訊息的
historyId(list回應中的第一則訊息)，以便日後進行部分同步處理。
部分同步處理
如果應用程式最近已同步處理，您可以使用 history.list 方法執行部分同步處理，以便傳回比在要求中指定的 startHistoryId 之後的所有歷史記錄。記錄會提供每則訊息的郵件 ID 和變更類型，例如自 startHistoryId 後新增、刪除的訊息，或經過修改的標籤。您可以從完整或部分同步處理中取得並儲存最新訊息的 historyId，以做為後續部分同步處理作業的 startHistoryId 提供。
限制
一般來說，系統會至少提供一週的記錄，而且通常不會超過一週。不過，可用記錄的可用時間範圍可能少很多，而且有時候記錄在極少數情況下可能會無法使用。如果用戶端提供的 startHistoryId 不在記錄記錄的可用範圍內，API 會傳回 HTTP 404 錯誤回應。在此情況下，您的用戶端必須如上一節所述執行完整同步處理。