このドキュメントでは、ベスト プラクティスのガイドラインを示します。詳しくは、パフォーマンスのヒントをご覧ください。
API を使用するケース
プログラムでリクエストを送信するには
ワークフローのあらゆる部分を自動化する場合も、ERP（企業資源計画）システムへのフックを作成する場合も、Content API を使用すると、在庫に変化があったらすぐに更新を送信できます。
フィードバックを即座に受け取るには
Content API では、データフィードの処理後にメールの概要を受け取るのではなく、すべてのリクエストに対するレスポンスを即座に受け取ります。大規模なバッチ リクエストでは、5 ～ 10 秒のレイテンシが想定されます。
商品データを頻繁に変更する
Content API では、変化の激しい商品在庫を 1 日に何度も増分更新できますが、データフィード全体を毎回送信するのは現実的ではありません。更新が個別に利用可能になった場合は、個別に送信し、複数の更新が行われるまで待たずに一括で処理してください。同様に、更新がバッチで利用できる場合は、バッチで送信します。個々のリクエストに分割しないでください。
複数のサブアカウントを管理するため
新しく作成された Merchant Center アカウントは 1 つのアカウントで、独自の商品データのセットが保持されます。ほとんどの場合はこれで問題ありませんが、アカウントの規模が拡大するにつれ、商品に対してより複雑な管理システムが必要になる場合もあります。この場合は、マルチクライアント アカウント（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 からの読み取り専用リクエスト（get または list）の実行: 販売者によっては、API を使用して商品の情報とステータスの更新を取得したい場合があります。商品情報はフィードによってのみ更新されるため、これは問題ありません。
API を使用して、サブアカウント（アカウント サービス）および/またはアカウント単位の税金と送料の設定（Accounttax サービスと Shippingsettings サービス）を管理する。これらはデータフィードで提供できる関数ではないため、API を使用してこれらの関数を管理することと競合することはありません。
データ フィードの使用から API の使用のみへ、またはその逆へ移行するには、どうすればよいですか？
現在データフィードを使用していて、商品の更新にのみ API を使用するように切り替える場合は、API を使用して商品データを再アップロードする必要があります。商品フィードを使用して商品を更新すると、商品情報は API によって管理されるため、商品をデータフィードから削除したり、データフィード自体を削除したりしても、Merchant Center アカウントから商品情報が削除されることはありません。商品をデータフィードまたはデータフィード自体から削除する場合は、データフィードの更新がないことを確認してください。そうしないと、データフィードが再び所有権を取得し、データフィードから商品を削除すると、その商品は削除されます。
現在、商品情報の表示に API のみを使用していて、商品情報のメインソースとしてデータフィードを使用したい場合は、Merchant Center アカウントに新しいデータフィードを追加するだけで、Merchant Center アカウントに追加済みの商品の所有権が与えられます。API のみを使用してアップロードされた、期限切れになる前に削除したい商品がある場合は、Merchant Center または API を使用して削除する必要があります。
Content API for Shopping を使って複数の国に商品を掲載するにはどうすればよいですか？
Content API で登録した商品の広告と無料リスティングで複数の国をターゲットに設定するには、Merchant Center の Content API メインフィードで国を追加するか、products リソースの shipping フィールドを使用して国を追加します。
Content API メインフィードの設定を変更する方法の例を次に示します。
詳しくは、複数の国でショッピング広告と無料リスティングをターゲットに設定するをご覧ください。
クライアント ライブラリが最新であることを確認する
Google クライアント ライブラリを使用して Content API を操作する場合は、選択したプログラミング言語のパッケージ マネージャーを使用し、ライブラリのバージョンが最新であることを確認してください。詳しくは、サンプルとライブラリで選択した言語のデベロッパー ガイドをご覧ください。
destination 属性を使用して、さまざまなショッピング プログラムに表示する商品をコントロールする
Content API は、Merchant Center で設定された Content API フィードのデフォルト設定を自動的に適用します。includedDestinations または excludedDestinations 商品属性を使用して、フィード内または Content API を介して、商品単位でプログラムへの参加を制御できます。
API フィードで「Google で購入」（旧称: ショッピング アクション）などのプログラムにオプトインしていて、特定の商品を除外する場合は、excludedDestinations 属性を使用して、値として Shopping Actions を指定します。エラーがなければ、Merchant Center のデフォルトのフィード設定が上書きされ、その特定の商品アイテムは「Google で購入」（旧称: ショッピング アクション）に表示されません。逆に、フィードでプログラム（ショッピングなど）を有効にしていない場合は、includedDestinations 属性と Shopping_ads を値として使用して商品アイテムを個別に指定すると、その商品アイテムがショッピング広告に表示されます。
includedDestinations と excludedDestinations の商品属性について詳しくは、ヘルプセンターをご覧ください。
有効期限が切れる前にアイテムを更新してください
アイテムが期限切れになる前に変更されない場合は、最後の更新から 30 日後、または指定した有効期限（以前の場合は指定された有効期限）にアイテムが更新され、無効になるのを避けることができます。どのアイテムも変更されていないか、最終更新日を追跡できないため、多くのアイテムを更新する必要がある場合は、すべてのアイテムを同時に更新するのではなく、複数の日に均等に負荷を分散します。
Content API フィードは削除しないでください。削除すると商品が表示されなくなる可能性があります
Content API を使って channel:online を使って初めて商品をアップロードすると、Merchant Center に「Content API」という名前の新しいフィードが表示されます。Content API を使って channel:local を使って初めて商品をアップロードすると、「Content API」というタイトルの新しいフィードが「ローカル商品」という小見出しとともに Merchant Center に表示されます。オンラインまたはローカルの Content API フィードを誤って削除しないようにしてください。削除するフィードに応じて、Content API を使用して Merchant Center に追加したオンライン商品またはローカル商品が削除されます。
custombatch メソッドを使用して同じサービスに対する複数のリクエストをバッチ処理する
同じサービスに対して多くの順次リクエストまたは並列リクエストを行うのではなく、必要なすべてのリクエストを含む単一のカスタムバッチ リクエストを作成します。このようにすると、API エンドポイントへのリクエストのレイテンシは、個々のリクエストではなく、custombatch 呼び出しで 1 回だけ発生します。これは、順次リクエストを実行する場合に特に重要です。
1 つのバッチで 1 つのアイテムに複数の更新を送信しない
これにより、更新の順序が不確実で予期しない結果が生じ、競合エラーが発生する可能性があります。
変更されていないアイテムの更新を送信しない
商品の有効期限が切れる場合を除き、新しい商品アイテム、変更した商品アイテム、削除した商品アイテムのみにリクエストを送信するようにしてください。
価格や在庫状況が急変する場合は補助フィードを使用します。
商品の価格、在庫状況、セール情報を最新の状態に保つのが難しい場合は、products リソースの補助フィードを使用して、それらの属性だけの更新を送信することをご検討ください。補助フィードの更新は小規模であるため、特定の期間には完全な商品の更新よりも多くの補助フィードの更新を行うことができます。これにより、商品の価格と在庫状況をランディング ページと一致させることができます。
商品の価格と在庫状況を更新するもう 1 つの方法は、商品アイテムの自動更新です。API の更新に加えてこれを使用すると、Merchant Center の情報と商品のランディング ページの情報の不一致を回避できます。ただし、これは商品価格と在庫状況の精度に関する小さな問題を修正することを目的としているため、商品アイテムの自動更新は、API を介して正しい情報を提供しても置き換えるものではありません。
更新トークンを使用するタイミング
更新トークンは、承認リクエストの HTTP ヘッダーで返されます。認証情報には他にも多くの情報が含まれていますが、アクセス トークンの有効期限は 60 分であるため、更新トークンを使用すれば、ユーザーに認証を繰り返し求める必要がなくなるため、デベロッパーが実際に使用したい部分が多くなります。