拠点に写真をアップロードする

拠点に1枚以上の画像を添付します。photos配列を指定してください。各項目には少なくともphotoを含めます。これは、Listings APIが取得して保存する画像の公開URLです。locationIdと、空でないphotos配列は常に必須です。

成功時の2つの形式

小規模なバッチはインラインでアップロードされます。上のサンプルのように、photosには処理済みのメディアが格納され、requestは空のオブジェクトになります。大規模なバッチは代わりにキューに登録され、同じ200が次のようになります。

{  "data": {    "addLocationPhotos": {      "clientMutationId": null,      "success": true,      "request": {        "requestId": "e6c2d9d9-9a18-4015-88cf-9a4e19a6f49a",        "status": "PROCCESSING"      },      "photos": [],      "errors": null    }  }}

どちらも成功なので、photosにデータが入っていると想定するのではなく、request.requestIdが存在するかどうかを確認して処理してください。

URLフィールドはphotoです。 urlでもimageでもありません。各項目には、このフィールドに加えて、任意でtype（LOGO、COVER、またはADDITIONAL）、starred、sourceを指定でき、パートナー連携用にpublisherOverrideとpartnerMediaIdも指定できます。返される写真にはcaptionフィールドがありません。

ユースケース：新しい拠点の画像を初期登録する。 「Jenny Home」などの拠点を作成した直後に、1回の呼び出しで、ロゴと店舗外観の写真のURLをPOSTします。レスポンスには新しい写真ごとのidが含まれます。このIDは、後でスター付けや削除のエンドポイントに渡します。

ユースケース：承認済みのアセットを複数の拠点で再利用する。 各拠点のphotos配列に、ホストされている同じ画像のURLを指定することで、すべての拠点が同じソースアセットを共有できます。

注意点。

• 画像はJPEGまたはPNGである必要があります。掲載先のサイズ規則はカテゴリごとに適用されます（一般的な下限は約10 KB、上限は数MBです）。
• 大規模なバッチは非同期で処理されます。サーバー側で定められたバッチサイズを超えると、呼び出しはインラインでアップロードする代わりに処理をキューに登録し、photosが空で返され、request.requestIdが設定されます。そのIDを使用してGET /locations/photos/requests/{requestId}をポーリングし、完了状況を追跡してください。しきい値はサーバー側の設定なので、固定の数値として扱うのではなく、「大規模なバッチはキューに登録される場合がある」と捉え、request.requestIdの有無に基づいて処理を分岐してください。
• request.statusの値に基づいて処理を分岐しないでください。キューに登録された場合のレスポンスでは、これは文字列リテラルPROCCESSINGであり、ポーリング用エンドポイントが同じジョブについて報告するPROCESSINGとは表記が異なります。request.requestIdが存在することが、信頼できる判断基準です。
• スター付き写真が上限の4枚を超えるようにstarred: trueを指定すると、呼び出し全体がSY15012で失敗します。このチェックでは、拠点の既存のスター付き写真と、このリクエスト内のスター付き項目を合算します。
• 拠点にはロゴとカバーがそれぞれ1枚だけ保持され、どちらのカテゴリも再アップロードすると既存の画像が置き換えられます。
• 画像をロゴまたはカバーにする場合は、typeを明示的に設定してください。指定しない場合、画像は追加の写真として保存されます。