メインコンテンツへスキップ

メニューの作成と更新

Marketplace APIs are limited access

弊社のマーケットプレイス統合パイプラインは、現在上限に達しています。加盟店オンボーディング用セルフサービスツール開発する当面の間は、新しいパートナーを受け付けておりません。統合の構築前にDoorDashにお問い合わせいただくには、 マーケットプレイス統合に関するお問い合わせ フォームにご入力ください。

以下の画像は、API を通したメニューの作成と更新の概要を示しています。

メニュー

メニューの作成（プル）​

GET /{merchant_pull_menu_endpoint}/{location_id}

統合ワークフローの一環として、パートナーは、DoorDash がメニューをプルできるようにするエンドポイントを実装する必要があります。これにより、新しい加盟店のオンボーディング時に、より合理化されたプロセスの使用が可能になります。DoorDash チームはメニューのプッシュをパートナーと調整せずに、加盟店の設定と対応メニューのプルを一度に行うことができるようになります。メニュー取り込みプロセスに対するレスポンスは、プッシュメゾットとして以下に記載された内容と一致します。この GET リクエストへのレスポンスは、プッシュリクエストによるものとは異なります。メニューは、レスポンスの一部として返すメニューが複数あるかどうかに関係なく、配列として含める必要があります。以下の例をご参照ください。

{
    "store": {
        "merchant_supplied_id": "<client's store id>",
        "provider_type": "<client’s DoorDash provider type>"
    },
    "menus": [
        {...},
        {...}
    ]
}

注意: 上記のサンプルレスポンスから分かるように、メニュープルリクエストのレスポンスは、たとえ返すメニューが 1 つしかなくてもメニューを配列として返さなければなりません。

メニュープルリクエストが失敗した場合、パートナーは、必要に応じて効率的にトリアージとエスカレーションが行えるように、適切なレスポンスコードを返す必要があります。

弊社サービスによってメニューの作成が完了した際、あるいはメニューの作成に失敗した際には、メニューの作成結果が含まれた POST Webhook リクエストをお送りします。御社が Webhook 通知を受信できるように、エンドポイントを作成し、その URL を弊社にお送りいただく必要があります。このリクエストには、御社からの最初のリクエストに対するレスポンスと同じ「reference」が h 含まれているため、どのリクエストの処理が完了したのかを把握していただけます。この Webhook の詳細は、「Receiving Menu Status Updates」セクションをご覧ください 。

メニューの作成（プッシュ）​

POST /api/v1/menus

DoorDash のメニュー作成パイプラインは非同期で機能します。POST エンドポイントへのリクエストが成功すると、ステータスコード「200」が入ったレスポンスが返されます。これは、DoorDash がメニューの作成のリクエストを正常に受け取ったことを示します。このリクエストの結果は、後ほどメニューステータス Webhook を通して返送されてきます。メニューの処理時間は、メニュージョブが作成された時点のキューのサイズに応じて変わります。メニュー処理にかかる時間は、平均で 1 分未満です。

メニューリクエストの本文には、「reference」フィールドが含まれていますが、これは省略可能です。これはメニュー作成リクエストを参照する ID で、加盟店が任意の値を提供します。この ID は、ステータスに対応する元のリクエストが突き止められるように、メニューステータス Webhook に含まれて返送されます。値が指定されなかった場合は、DoorDash がこの ID を入力し、DoorDash によって生成された ID がメニュー POST へのレスポンスに含まれて返送されます。このフィールドの値を、空の文字列や null 値にはしないでください。

メニューリクエストの本文には、バージョン番号なしのプロバイダタイプの情報を提供する provider_type フィールドが含まれます。たとえば、ヘッダーが「"User-Agent": DoordashClient/1.0」の場合、呼び出しの本文内の「provider_type」フィールドに入力して提供する値は、「"provider_type": "doordash_client"」となります。

弊社サービスによってメニューの作成が完了した際、あるいはメニューの作成に失敗した際には、メニューの作成結果が含まれた POST Webhook リクエストをお送りします。御社が Webhook 通知を受信できるように、エンドポイントを作成し、その URL を弊社にお送りいただく必要があります。このリクエストには、御社からの最初のリクエストに対するレスポンスと同じ「reference」が入っているため、どのリクエストの処理が完了したのかを把握していただけます。この Webhook の詳細は、「Receiving Menu Status Updates」セクションをご覧ください 。

メニューの更新（プッシュ）​

PATCH /api/v1/menus/{id}

メニュー作成時に、 DoorDash のメニューステータス Webhook によって、POST リクエストに含まれた「"id": "menu-id"」（UUID）が送信されます。メニューを更新する場合は、このメニュー ID を URL パラメータに入れていただく必要があります。メニューの処理時間は、メニュージョブが作成された時点のキューのサイズに応じて変わりますが、平均のメニュー処理時間は 1 分未満です。

メニュー更新パイプラインは、メニュー作成パイプラインと同じように機能します。メニュー更新時には、更新したい特定のフィールドだけでなく、メニュー全体をリクエストに含める必要があります。よって、PATCH エンドポイントのデータ検証には POST エンドポイントと同じモデルが使用されるため、PATCH エンドポイントのデータ検証は POST エンドポイントのプロセスと同じように機能します。POST の場合と同じく、リクエストを識別するためにペイロードで「reference」フィールドを指定することができますが、DoorDash が生成する参照を使用しても構いません。

弊社サービスによるメニューの更新が完了または失敗した場合、ご指定いただいたエンドポイントに POST Webhook リクエストをお送りします。詳細については、以降のセクション「Receiving Menu Status Updates」をご覧ください。

メニューの更新（プル）​

GET /{merchant_pull_menu_endpoint}/{location_id}[?ids=external_menu_ids]

パートナーは同じプルエンドポイントを使用して、外部メニュー ID のリストに基づいたメニューの更新をリクエストできます。これにより、DoorDash 側で柔軟にメニューを同期させることができます。ここでは、POS 内で変更が行われたときにメニューの更新を自動的にトリガーするよう、プッシュロジックをプロバイダー側で構築することをおすすめします。

メニューのレスポンスコード：​

ステータスコード詳細
200成功
400不正なリクエスト
403閲覧禁止
429リクエストが多すぎます。
500内部サーバーエラー

「429」を受け取った場合、1 分後に再試行してください。「500」を受け取った場合、指数バックオフで再試行してください。「400」のレスポンスを受け取った場合は、再試行しないでください。「400」ステータスコードに加え、問題の発生源の診断に役立つエラーメッセージが表示されます（以下の例を参照）。

400 Bad Request: Invalid menu payload: [StoreMenu.menu.MenuCategory[IcedBeverages]: find duplicate merchant id:5757, name:Freshly Brewed Iced Coffee - Create Your Own - Custom.]

上記の例では、「5757」の「merchant_supplied_id」が商品がすでに存在します。これは、同じメニューレベル内の商品で重複している ID があることを示しています。このエラーを解決するには、同じメニューレベル内の商品に一意の「merchant_supplied_ids」を用意する必要があります。

メニューフィールドの長さの上限​

メニューペイロード内のフィールドが許容される最大の長さを超えると、「400 不正なリクエスト」のレスポンスによりメニューは失敗します。以下に記載されているフィールドの上限に従ってください。

フィールド長さの上限
メニュー
名前500
サブタイトル500
merchant_supplied_id1024
カテゴリー
名前500
サブタイトル500
merchant_supplied_id1024
Item、ItemExtra、ItemExtraOption
名前500
説明1000
merchant_supplied_id1024

注意すべきメニューフィールド​

  • reference: メニュープルレスポンスの必須フィールドで、ID（外部メニュー ID）にリンクされる加盟店メニュー ID です。
  • id （外部メニュー ID）: イベントタイプが「MenuUpdate」の場合は必須です。メニューの作成時に返され、MenuCreate 後に加盟店はこれを保存しておく必要があります。
  • original_image_url: メニュー API を介して自動的に画像を取得するために使用します。詳細は、「よくある質問」セクションをご覧ください。
  • nutritional_info: 商品および代替品のカロリー情報を定義するために使用します。
  • classification_tags: 商品や代替品の栄養タグを指定するために使用します。