本文档提供了最佳实践指南。如需了解详情，请参阅性能提示。
何时使用 API
以编程方式发送请求
无论您是希望自动执行工作流的每个部分，还是创建到 ERP（企业资源规划）系统中的钩子，Content API 都可以让您在库存发生变化后立即发送更新。
获取即时反馈
在 Content API 中，您可以立即收到每个请求的响应，而不是在数据 Feed 处理完毕后通过电子邮件摘要收到响应。大批量请求的延迟时间预计为 5 到 10 秒。
经常更改商品数据
借助 Content API，您可以在一天内多次对快速移动的商品目录进行增量更新，而每次发送整个数据 Feed 并不可行。如果更新逐个可用，请单独发送这些更新，不要等到有多项更新后再将它们批量发送。同样，如果可批量提供更新，请分批发送，不要将更新分解为多个单独的请求。
管理多个子帐号
新创建的 Merchant Center 帐号是单个帐号，保留着自己的一组商品数据。这在大多数情况下效果都很好，但随着帐号规模的扩大，您可能会发现您需要一个更复杂的产品管理系统。在这种情况下，请考虑使用多客户帐号 (MCA)。可通过 Accounts 服务对 MCA 帐号进行 API 级管理，并允许以编程方式添加和管理子帐号。如需详细了解如何获取 MCA 帐号，请点击此处。
如何使用该 API
不要像使用数据 Feed 那样使用 API
使用 products 资源时，请避免每天更新整个商品 Feed。您只能专门更新数据实际发生了更改的商品。对 Google 和您来说，通过 products 资源发送整个数据 Feed 会消耗更多的时间和资源。
请勿使用 API 定期检索您上传的商品信息
如果您负责维护特定 Merchant Center 帐号中的商品信息，请避免定期通过 products.get 或 products.list 方法从 Content API 请求商品信息。对于上传信息的客户，这些方法可帮助您在设计使用 Content API 的解决方案时调试问题。但是，它们并不用于此类客户端定期检索商品信息。您应该有其他的商品信息来源（例如本地商品数据库），并且 Merchant Center 中的商品应反映该来源的内容。
请勿同时使用数据 Feed 和 Content API 来提交商品
如果您正在考虑改用 API 来提交商品，请确保您不再使用数据 Feed 来提交商品。如果您继续通过这两种媒介提交商品，可能会出现意外结果。
有没有办法可以安全地结合使用 API 和数据 Feed？
您可以使用 API 的数据 Feed 服务来操控数据 Feed。虽然这会大大简化大规模的数据 Feed 管理工作，但请注意，您不应同时使用 API 和 Feed 插入或更新商品，因为可能会出现意外结果。
结合使用 Feed 和 API 的一些其他可接受方式的示例包括：
从 API 执行只读请求（get 或 list）：有些商家希望使用 API 来获取商品的信息和状态更新。这是可以接受的，因为商品信息仅通过 Feed 更新。
使用 API 管理您的子帐号（Accounts 服务）和/或帐号级税费和运费设置（Accounttax 服务 和 Shippingsettings 服务）。这些不是 Datafeeds 可以提供的函数，因此与使用 API 管理这些函数不会发生冲突。
如何从使用数据 Feed 迁移到仅使用 API，反之亦然？
如果您目前在使用数据 Feed，并且想改为仅使用 API 来更新商品，则需要使用该 API 重新上传商品数据。当您使用商品服务更新指定商品时，API 会控制商品信息，如果从数据 Feed 中删除商品或删除数据 Feed 本身，则不再会从您的 Merchant Center 帐号中移除商品信息。如果您要从数据 Feed 或数据 Feed 中移除商品，请确保没有任何数据 Feed 更新，否则数据 Feed 会重新获得所有权，而从数据 Feed 中移除商品会导致商品被移除。
如果您目前仅使用 API 处理商品信息，并且希望使用数据 Feed 作为商品信息的主要来源，那么只需将新数据 Feed 添加到 Merchant Center 帐号中，它们就会获得所列出的商品的所有权。如果您希望在过期前移除仅通过 API 上传的商品，则必须通过 Merchant Center 或 API 将其删除。
如何使用 Content API for Shopping 面向多个国家/地区销售商品？
如需针对通过 Content API 提交的商品的广告和非付费商品详情定位到多个国家/地区，请在 Merchant Center 中的 Content API 主要 Feed 中配置其他国家/地区，或者通过 products 资源中的 shipping 字段添加这些其他国家/地区。
以下示例展示了如何修改 Content API 主要 Feed 设置。
如需了解详情，请参阅：在多个国家/地区定位购物广告和非付费商品详情。
确保您的客户端库是最新版本
如果您使用 Google 客户端库与 Content API 交互，请务必使用适用于您所选编程语言的软件包管理器，并确保库版本为最新版本。如需了解详情，请参阅示例和库中所选语言的开发者指南。
请务必使用平台属性来控制在不同购物计划中展示哪些商品
Content API 会自动采用您在 Merchant Center 中配置的 Content API Feed 的默认设置。您可以使用 includedDestinations 或 excludedDestinations 商品属性，在 Feed 内或通过 Content API 控制计划参与情况。
如果您的 API Feed 已加入“在 Google 上购买”（以前称为“购物行动”）计划，但您希望排除某些商品，请使用 excludedDestinations 属性并指定 Shopping Actions 作为值。如果没有错误，这将覆盖 Merchant Center 中的默认 Feed 设置，并且特定商品不会显示在“在 Google 上购买”（以前称为“购物行动”）中。相反，如果您的 Feed 尚未选择加入 Google 购物等计划，您可以使用 includedDestinations 属性并将 Shopping_ads 作为值，将具体商品纳入其中，让商品出现在购物广告中。
如需详细了解 includedDestinations 和 excludedDestinations 商品属性，请参阅帮助中心。
确保在商品过期之前进行更新
如果商品在过期之前没有更改，则在上次更新 30 天后或指定的过期日期（如果更早）更新商品，以免商品被停用。如果您需要更新许多项（因为它们都未更改或者您无法跟踪这些项的上次更新时间），请不要同时更新所有项，而应将负载均匀地分散到多天。
请勿删除 Content API Feed，否则您的商品可能会消失
首次通过 Content API 使用 channel:online 上传商品时，Merchant Center 中会出现一个名为 Content API 的新 Feed。首次通过 Content API 使用 channel:local 上传商品时，Merchant Center 中会出现一个名为 Content API 的新 Feed，其子标题为本地商品。请确保您不会意外删除在线或本地 Content API Feed。根据您删除的 Feed，您通过 Content API 添加到 Merchant Center 中的在线商品或本地商品将被移除。
使用 custombatch 方法对同一服务的多个请求进行批处理
不要向同一服务发出许多连续或并行请求，而应发出包含所有所需请求的单个 custombatch 请求。这样，向 API 端点发出请求时，只有 custombatch 调用会出现一次延迟，而不是每个单独的请求发生一次，这在您发出顺序请求时尤为重要。
不要一次性批量向单件商品发送多个更新
由于更新顺序的不确定性，这将导致结果不符合预期，并可能导致冲突错误。
不针对未更改的商品发送更新
请确保您仅针对全新、已更改或已删除的商品发送请求，除非这些商品将过期。
如果价格和/或库存状况快速变化，请使用补充 Feed
如果您无法及时更新商品的价格、库存状况或促销信息，请考虑使用 products 资源中的补充 Feed 仅针对这些属性发送更新。由于补充 Feed 更新规模较小，因此与完整的商品更新相比，您可以在指定时间段内进行更多补充 Feed 更新，这样有助于使商品的价格和库存状况与着陆页保持一致。
更新商品价格和库存状况的另一个途径是使用自动商品更新。此 API 可用作 API 更新的补充，有助于避免 Merchant Center 中的信息与商品着陆页上的信息不一致。但请注意，此功能旨在修复商品价格和库存状况准确性方面的小问题，因此自动商品更新不能取代通过 API 提供正确信息。
何时使用刷新令牌
刷新令牌会在授权请求的 HTTP 标头中返回。该令牌包含许多其他与身份验证相关的信息，但刷新令牌通常是开发者想要获取的部分，因为访问令牌的有效期仅为 60 分钟，因此无需反复提示用户进行身份验证。