本文提供最佳做法指南。詳情請參閱效能提示。
API 的使用時機
以程式輔助方式傳送要求
無論您偏好自動執行工作流程的每個環節，還是想建立 ERP (企業資源規劃) 系統的掛鉤，只要商品目錄有變動，Content API 都能讓您立即傳送更新。
如要立即收到意見回饋
在 Content API 中，系統會立即回應每個要求，而不是在處理完資料動態饋給後，透過電子郵件摘要回覆。大量批次要求預計會出現 5 到 10 秒的延遲。
如要經常變更產品資料
透過 Content API，你可以在一天內多次增量更新快速銷售的產品庫存，但每次都傳送完整資料動態饋給並不可行。如果個別更新可用，請個別傳送，不要等到有多個更新再批次傳送。同樣地，如果可批次更新，請以批次形式傳送，不要分成個別要求。
如何管理多個子帳戶
新建立的 Merchant Center 帳戶是單一帳戶，會保留自己的產品資料集。在大多數情況下，這種做法都相當有效，但隨著帳戶規模擴大，你可能會發現需要更複雜的產品管理系統。如果符合上述情況，建議使用多重客戶帳戶 (MCA)。您可透過帳戶服務，在 API 層級管理 MCA 帳戶，並以程式輔助方式新增及管理子帳戶。如要進一步瞭解如何取得 MCA 帳戶，請參閱本文。
如何使用 API
請勿將 API 當成資料動態饋給使用
使用 products 資源時，請避免每天更新整個產品動態饋給。
請改為只更新資料實際變更的產品。透過 products 資源傳送整個資料動態饋給，會耗費 Google 和你更多時間和資源。
請勿使用 API 定期擷取你上傳的產品資訊
如果你負責維護特定 Merchant Center 帳戶中的產品資訊，請避免定期透過 products.get 或 products.list 方法，向 Content API 要求產品資訊。對於上傳資訊的客戶，這些方法可協助您在設計使用 Content API 的解決方案時，偵錯問題。不過，這類用戶端不應定期擷取產品資訊。你應該有其他產品資訊來源 (例如店面產品資料庫)，且 Merchant Center 中的產品應反映該來源的內容。
請勿同時使用資料動態饋給和 Content API 提交產品項目
如果考慮改用 API 提交商品項目，請確認你不再使用資料動態饋給提交產品項目。如果繼續透過這兩種管道提交商品，可能會發生非預期的結果。
有什麼方法可以安全地同時使用 API 和資料饋給？
你可以使用 API 的資料動態饋給服務來操控資料動態饋給。雖然這樣做可大幅簡化大規模資料動態饋給管理作業，但請注意，你不應使用 API 和動態饋給同時插入或更新產品，否則可能會發生非預期結果。
以下列舉其他可接受的資訊提供和 API 共同使用方式：
透過 API 執行唯讀要求 (取得或列出)：部分商家想透過 API 擷取產品的資訊和狀態更新。這是可接受的，因為產品資訊只會透過動態饋給更新。
使用 API 管理子帳戶 (帳戶服務) 和/或帳戶層級的稅金和運送設定 (帳戶稅金服務和運送設定服務)。這些並非 Datafeeds 可提供的功能，因此使用 API 管理這些功能時不會發生衝突。
如何從使用資料動態饋給改為只使用 API，或反過來操作？
如果你目前使用資料動態饋給，並想改為只使用 API 更新產品，則須透過 API 重新上傳產品資料。使用 products 服務更新特定產品時，API 會控管產品資訊，因此從資料動態饋給中刪除產品或刪除資料動態饋給本身，都不會再從 Merchant Center 帳戶中移除產品資訊。如要從資料動態饋給或資料動態饋給本身移除產品，請確保沒有資料動態饋給更新，否則資料動態饋給會再次取得擁有權，從資料動態饋給移除產品會導致產品遭到移除。
如果您目前只使用 API 取得產品資訊，並想改用資料動態饋給做為產品資訊的主要來源，只要將新的資料動態饋給新增至 Merchant Center 帳戶，系統就會將列出的產品擁有權轉移給該動態饋給。如果想在產品到期前移除僅透過 API 上傳的產品，必須透過 Merchant Center 或 API 刪除產品。
如何使用 Content API for Shopping，將產品指定至多個國家/地區？
如要透過 Content API 提交的產品，在多個國家/地區放送廣告和免費產品資訊，請在 Merchant Center 的 Content API 主要動態饋給中設定其他國家/地區，或透過 products 資源的 shipping 欄位新增其他國家/地區。
以下範例說明如何修改 Content API 主要動態饋給設定。
詳情請參閱： 在多個國家/地區放送購物廣告和免費產品資訊。
確認用戶端程式庫為最新版本
如果您使用 Google 用戶端程式庫與 Content API 互動，請務必使用所選程式設計語言的套件管理員，並確保程式庫版本為最新版本。詳情請參閱「範例和程式庫」中，所選語言的開發人員指南。
請務必使用目的地屬性，控管不同購物方案中顯示的產品
Content API 會自動採用你在 Merchant Center 中設定的 Content API 動態饋給預設設定。你可以使用 includedDestinations 或 excludedDestinations 產品屬性，在動態饋給中或透過 Content API，控管產品層級的方案參與情況。
如果 API 動態饋給已加入計畫 (例如 Buy on Google，舊稱 Shopping Actions)，但你想排除特定產品，請使用 excludedDestinations 屬性，並將值設為 Shopping Actions。如果沒有錯誤，這會覆寫 Merchant Center 中的預設動態饋給設定，且該特定商品不會顯示在 Buy on Google (舊稱購物行動) 中。反之，如果動態饋給未加入任何計畫 (例如購物)，你可以使用 includedDestinations 屬性並將值設為 Shopping_ads，將個別商品加入購物廣告。
如要進一步瞭解 includedDestinations 和 excludedDestinations 產品屬性，請參閱說明中心。
請務必在項目到期前更新
如果商品在到期前未變更，請在上次更新後 30 天內或指定到期日 (以較早者為準) 更新商品，以免商品遭到停用。如果需要更新大量項目，但這些項目都沒有變更，或是您無法追蹤上次更新時間，請不要同時更新所有項目，而是將負載平均分散在多天內。
請勿刪除 Content API 動態饋給，否則產品可能會消失
首次透過 Content API 上傳產品時，Merchant Center 中會顯示名為「Content API」的新動態饋給。channel:online首次透過 Content API 上傳產品時，Merchant Center 會顯示名為「Content API」的新動態饋給，並附上「店面產品」的副標題。channel:local請務必不要誤刪線上或本機的 Content API 動態饋給。視刪除的動態饋給而定，透過 Content API 新增至 Merchant Center 的線上或店面產品將會移除。
使用 custombatch 方法，將對同一服務的多個要求批次處理
請勿對同一項服務發出多個循序或並行要求，而是發出包含所有所需要求的單一自訂批次要求。這樣一來，向 API 端點發出要求的延遲時間只會發生一次 (針對 custombatch 呼叫)，而不是針對每個個別要求，如果您發出連續要求，這點就特別重要。
請勿在單一批次中，對單一項目傳送多項更新
由於更新順序不確定，這會導致非預期的結果，並可能造成衝突錯誤。
不要傳送未變更項目的更新
請務必只傳送新增、變更或刪除產品項目的要求，除非項目即將過期。
如果價格和/或供應情形變動快速，請使用補充動態饋給
如果無法及時更新產品的價格、供應情形或特價資訊，建議使用products 資源中的補充動態饋給，只傳送這些屬性的更新資訊。由於補充動態饋給更新的資料量較小，因此在特定時間內，你可以進行的補充動態饋給更新次數，會比完整產品更新多出許多，有助於確保產品價格和供應情形與到達網頁一致。
如要更新產品價格和供應情形，也可以使用商品自動更新功能。除了使用 API 更新，你也可以使用這項功能，避免 Merchant Center 中的資訊與產品到達網頁上的資訊不一致。不過請注意，這項功能旨在修正產品價格和供應情形準確度的小問題，因此商品自動更新功能無法取代透過 API 提供正確資訊。
使用更新權杖的時機
授權要求的 HTTP 標頭會傳回重新整理權杖。其中包含許多其他驗證相關資訊，但開發人員通常想取得的是重新整理權杖，因為存取權杖的效期只有 60 分鐘，有了重新整理權杖，就不必重複提示使用者驗證。