本文件提供最佳做法的指南。詳情請參閱「效能提示」一文。
使用 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 服務來操控資料動態饋給。雖然這樣可以簡化大規模資料動態饋給的管理作業，但請注意，請勿搭配使用 API 與動態饋給插入或更新產品，因為可能會發生未預期的結果。
以下列舉幾種可接受同時使用動態饋給和 API 的方式：
執行 API 的唯讀要求 (取得或列出)：部分商家想使用 API 擷取產品的相關資訊和狀態更新。這是可接受的做法，因為產品資訊只會透過動態饋給更新。
使用 API 管理子帳戶 (帳戶服務) 和/或帳戶層級的稅金和運送設定 (Accounttax 服務和運送設定服務)。 這些函式並非 Datafeeds 提供的函式，因此使用 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 (舊稱 Shopping Actions)，但想排除特定產品)，請使用 excludedDestinations 屬性並指定 Shopping Actions 值。如果沒有任何錯誤，系統就會覆寫 Merchant Center 中的預設動態饋給設定，且該特定商品不會在 Buy on Google (舊稱 Shopping Actions) 中顯示。反之，如果您的動態饋給未加入計畫 (例如購物)，則使用 includedDestinations 屬性和 Shopping_ads 做為值，即可將商品顯示在購物廣告中。
如要進一步瞭解 includedDestinations 和 excludedDestinations 產品屬性，請參閱說明中心。
請務必在過期前更新商品
如果項目未在到期前變更、上次更新後的 30 天或指定到期日 (如更早)，請更新項目以免停用。如果您需要更新許多項目，因為所有項目都沒有變更，或是您無法追蹤其上次更新的時間，請不要同時更新所有項目，而是將負載平均分散至多天。
請勿刪除 Content API 動態饋給，否則產品可能會消失
您第一次透過 Content API 使用 channel:online 上傳產品時，新的動態饋給會顯示在 Merchant Center 中，標題為「Content API」。您第一次透過 Content API 使用 channel:local 上傳產品時，新的動態饋給會顯示在 Merchant Center 中，標題為「Content API」，且子標題為「Local Products」。請勿意外刪除線上或本機 Content API 動態饋給。視您刪除的動態饋給而定，您透過 Content API 新增至 Merchant Center 的線上或店面產品會遭到移除。
使用 custombatch 方法向同一項服務批次發出多個要求
請勿對同一項服務發出多次連續或平行要求，而是只需提出包含所有所需要求的單一自訂批次要求。這樣一來，針對自訂批次呼叫，向 API 端點發出要求的延遲時間只會出現一次，而非每次發出個別要求時，這對發出序列要求來說特別重要。
請勿在單一批次中將多項更新傳送給單一項目
這可能會因更新序列的不確定性而產生非預期的結果，並可能導致衝突錯誤。
不要針對未變更的項目傳送更新
請務必只傳送新增、變更或刪除產品項目的要求，除非這些項目有到期日。
如果價格和/或供應情形迅速變動，請使用補充動態饋給
如果無法確保產品的價格、供應情形或特價資訊符合現況，請考慮使用 products 資源中的補充動態饋給，只傳送這些屬性的更新資訊。由於補充動態饋給的更新資料規模較小，相較於完整的產品更新，您可以在特定期間進行更多補充動態饋給更新，確保產品的價格和供應情形與到達網頁一致。
另一個更新產品價格和供應情形的方法是使用商品自動更新功能。這麼做可以代替 API 更新，避免 Merchant Center 中的資訊與產品到達網頁中的資訊不一致。不過請注意，這項功能旨在修正產品價格和供應情形準確性的小問題，因此商品自動更新功能無法取代透過 API 提供正確資訊。
使用更新權杖的時機
更新權杖會在授權要求的 HTTP 標頭中傳回。這個權杖包含許多其他驗證相關資訊，但更新權杖通常是開發人員想要取得的資訊，因為這樣就不必重複提示使用者進行驗證，因為存取權杖會在到期前 60 分鐘才過期。