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