共通エラー応答
Rapid API各事業部門では、エラーコード、メッセージ、および応答 形式が共通しています
これらのエラーは、Rapidのすべての事業分野に共通して適用されます。具体的には以下の通りです：
- Rapid Lodging API
- Rapid Car API
- Rapid Flight API
- Rapid Activities API
事業部門ごとの相違点については、その都度記載しています。
Rapid APIエラー処理
問題の発生を防ぐため、エラー処理のロジックには以下の点を盛り込むことをお勧めします：
- ショッピングおよび予約APIのエラーに対処するためのエラー処理ロジックが確実に実装されていることを確認してください。
- 以下の注意事項に特に記載がない限り、予約リクエストごとに必ず固有の
affiliate_reference_idを使用してください。 - エラー処理のロジック、特に予約リクエストに関するものは、定期的に見直して更新してください。
- Rapid APIのすべてのレスポンスには、対応するのHTTPレスポンスコードが割り当てられています。
接続タイムアウトまたは通信タイムアウト
Flight APIの予約リクエストについては 、API接続のタイムアウトを120秒に設定することをお勧めします。宿泊施設やその他のAPIについては、90秒に設定することをお勧めします。ただし、ショッピングの在庫状況確認の呼び出しについては、接続タイムアウトを短く設定することも可能です。
120秒以内に応答がない場合、Rapid APIは5xxエラーを返します。これは、Rapid API'sの接続タイムアウトが120秒に設定されているためです。
場合によっては、Rapid APIでは HTTP Expect: 100-Continue プロセス。このプロセスを使用してサーバーに接続しようとすると、接続の問題が発生する場合があります。特に、cURL、C#/.NET、およびデフォルトでこのプロセスに従うその他のプログラミング言語では、その傾向が強くなります。
注 : HTTP 504 のゲートウェイタイムアウトが発生しても、Rapidでタイムアウトが発生したというわけではありません。このような場合、インフラストラクチャ・サービスに障害が発生しているか、あるいはRapidが別の下流サービスへのゲートウェイとして機能しており、そのサービスに対してタイムアウト制限を設定しているかのいずれかです。そのダウンストリームのタイムアウトは、504エラーとして発生します。予約に関する呼び出しで504エラーが 発生した場合は、その予約が「旅程取得（Itinerary Retrieve）」機能（affiliate_reference_id+ email）を使用して作成されたかどうかをご確認ください。下流側の問題は、予約作成前（ホテルとの通信、決済サーバー）または作成後（Expedia Group財務管理）に発生した可能性があるためです。また、インターネット接続が安定しているかご確認ください。Traceroute コマンドで接続の問題を特定できる場合もあります。
予約と取得 5xx エラーの処理
予約エラー（5xxステータス）やタイムアウトが発生したからといって、必ずしもその予約自体が無効になるわけではありません。予約が作成された後にエラーが発生した可能性があります。ご予約の状況を確認するため、affiliate_reference_id への「旅程照会」とメールの送信をお勧めいたします。
90秒以内に返されたエラーは、予約の最終的なステータスを示すものではありません。通常、ほとんどの予約は13～30秒以内に確定しますが、場合によっては最大5分ほどかかることもあります。
90秒の間に3回まで、予約のステータスを確認するロジックを実装することができます。ほとんどの応答は最初の30秒以内に確認されますので、90秒間待 たずにその応答を確認することができます。最終的な応答が届かない場合は、30分間、取得操作を再試行していただけます。その後、さらなるサポートが必要な場合は、Rapid APIのコールセンター担当者までご連絡ください。
Retrieve API呼び出しを使用して、double-confirmに予約結果をリクエストしてください（HTTP 200またはHTTP 404のレスポンスが返されます）。
Retrieve の応答が Hold\Resume 情報を返す
宿泊予約が正常に完了した後、時折、「旅程の取得」のレスポンスとして、保留中または再開中の予約に関するもののように見えるデータが返されることがあります。そのため、通常予想される予約情報（客室、キャンセル料など）ではなく、返信には予約の保留・再開に必要なトークンのみが含まれます。
その理由は、その予約は有効ではありますが、まだ「保留中」のフラグが付いているためです。通常、この現象は数分以内に解消されるため、予約が完了するまで Itinerary Retrieve リクエストを繰り返してください。
レス ポンスの例 :
{
"itinerary_id": "2667552437552",
"links": [
{
"rel": "retrieve",
"method": "GET",
"href": "/v3/itinerary/{itinerary_id}?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
},
{
"rel": "resume",
"method": "PUT",
"href": "/v3/itinerary/{itinerary_id}?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
},
{
"rel": "cancel",
"method": "DELETE",
"href": "/v3/itinerary/{itinerary_id}?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
}
]
}複数のレベルに分類されるエラー
single-levelエラーでは必要な詳細をすべて説明できない場合、APIの応答ではエラーを複数のレベルに分類することがあります。すべてのレベルにわたって情報を確認していくことで、エラーの原因を特定し、解決に役立てることができます。
応答の例 :
{
"type": "invalid_input",
"message": "An invalid request was sent in, please check the nested errors for details.",
"errors": [
{
"type": "duplicate_itinerary",
"message": "An itinerary already exists with this affiliate reference id.",
"fields": [
{
"name": "affiliate_reference_id",
"type": "body",
"value": "XXXXXX"
}
]
}
]
}HTTP 応答コード
400 - Bad Request
リクエストの形式が不適切であったり、不正な値が含まれていたりする場合に返されます。
コード400「Bad Request」エラーは、Request Bookingヘッダーに問題があることを示しています。エラー応答には、予約リクエストのヘッダーに含まれる、実際に無効なエラー配列のフィールドが含まれます。ヘッダーは、roomsやpaymentsなどの複数の配列とsub-arrays, で構成されています。配列全体が本文です。つまり、body.email はヘッダー本文のメールパラメーターを示します。
注： Lodging APIでは、Bookingヘッダーのrooms配列のエントリ数は、Availability呼び出しでリクエストされた客室数と一致している必要があります。
「Tomcat Exception Report」とラベル付けされた 400 Bad Request エラーは、通常は Property Content API と Get Availability API でリクエストパラメーターが大きすぎる場合に返されます。このエラーを回避するには、プロパティの数を減らすか、リクエストから不要なパラメーターを削除します。
応答の例 :
ご希望の言語は対応していません :
{
"type": "invalid_input",
"message": "An invalid request was sent in, please check the nested errors for details.",
"errors": [
{
"type": "language.not_supported",
"message": "Language is not supported. Supported languages are: [de-DE, en-US, es-ES, es-MX, fr-FR, id-ID, it-IT, ja-JP, ko-KR, pt-BR, zh-CN]",
"fields": [
{
"name": "language",
"type": "querystring",
"value": "xx-XX"
}
]
},
{
"type": "filter.mismatch",
"message": "Existing booking is expedia_collect, this cannot be changed",
"fields": [
{
"name": "filter",
"type": "querystring",
"value": "property_collect"
}
]
}
]
}バージョン値が未記入 :
{
"type": "version.required",
"message": "You have not specified a version, the supported versions are: [1, 2]",
"fields": [
{
"name": "version",
"type": "path",
"value": "missing"
}
]
}無効なバージョン値 :
{
"type": "version.unsupported",
"message": "You have requested a version that is not supported, supported versions are: [1, 2]",
"fields": [
{
"name": "version",
"type": "path",
"value": "3"
}
]
}401 - Unauthorized
HTTP認証ヘッダーが欠落しているか、解析できなかった場合にこのメソッドが返されます。Rapid Lodging APIへの各リクエストには、APIキー、共有シークレット、およびUNIXタイムスタンプ（秒単位）を連結した文字列のハッシュ値（unsalted SHA-512 hash）を含める必要があります。詳細については、シグネチャー認証のページを参照してください。
Lodging APIの401未認証エラーの例：
{
"type": "request_unauthenticated",
"message": "Data required to authenticate your request is missing. Ensure that your request follows the guidelines in our documentation.",
"fields": [
{
"name": "apikey",
"type": "header",
"value": "jaj3982k239dka328e"
},
{
"name": "signature",
"type": "header",
"value": "129d75332614a5bdbe0c7eb540e95a65f9d85a5b53dabb38d19b37fad6312a2bd25c12ee5a82831d55112087e1b"
},
{
"name": "timestamp",
"type": "header",
"value": 198284729
},
{
"name": "servertimestamp",
"type": "server",
"value": 198284729
}
]
}Rapid Flight APIを呼び出す際は、リクエストヘッダーに有効なEGTokenプリンシパルJSON Webトークン（JWT） を必ず含める必要があります。
Authorization: EGToken principal-JWT={encodedJwt}プライマリJWTは、OAuth 2.0のクライアント認証情報およびトークン交換を通じて取得されます。詳細については、『』のOAuth 2.0認証に関するガイド（）および『Rapid Flight Booking API』（）の使用ガイドをご参照ください。
403 - Forbidden
HTTP 認証ヘッダーは有効ですが、リクエストされたリソースへのアクセス許可がない場合に返されます。
403 禁止応答の例
{
"type": "request_unauthorized",
"message": "Your request could not be authorized."
}404 - Not Found
リクエストされた API のリソースが検出できない場合に返されます。EAN の記載例で、リクエストした URL を確認してください。
LodgingGeography APIおよびContent APIも、リクエストされた地理情報ファイルやcontent-specificファイル、あるいはリソースが見つからない場合、404レスポンスを使用してその旨を示します。詳しい例については、それぞれの文書ページを参照してください。
Itinerary Retrieve の後のコード 404 は、予約が見つからなかったことを示します。予約エラーのために取得が行われた場合、予約が作成されなかったと表示されます。ただし、「Itinerary Retrieve API」のリクエストパラメータが有効であることを確認する必要がありますので、「Retrieveaffiliate_reference_id」、メールアドレス、および／または旅程番号が正しいことをご確認ください。また、Retrieve APIの呼び出しがBookingの呼び出しから90秒以内に実行された場合は、再度Retrieveを試してみることをお勧めします。
応答の例 :
{
"type": "resource.not_found",
"message": "The requested resource could not be found."
}409 - Price mismatch
多くのサプライヤーは、ダイナミックプライシング、あるいは「time-basedプライシング」とも呼ばれる価格設定を採用しています。そのため、需要と供給のアルゴリズムに基づいて価格が変動します。Expedia Group 1秒に数回、最新のレートを受け取ります。つまり、レートは頻繁に変化します。
ここで留意すべき重要な点は、これは通常、供給業者側の判断によるものであり、Expedia Group. さらに、料金や空室状況については複数のレベルでキャッシュが行われているため、予約処理の過程で複数のレイヤーにわたる遅延が生じる可能性があります。
価格の不一致（PMM）は想定される状況であり、システムの不具合や、システムが最新の価格を反映していないことなど、さまざまな理由で発生する可能性があります。これらの事象の発生頻度を監視し、発生率が急激に上昇したり、閾値に達したりした場合は、サポートまでご連絡ください。
複数の結果に対して同時にPMMが発生した場合は、急激な劣化の可能性がないか確認してください。
PMMが長期間にわたり同じ結果を返す場合は、おそらくサプライヤーによるレート設定の誤りが原因であると考えられます。確認をご希望の場合は、テクニカルサポートまでお問い合わせください。
PMMから復旧するには、「Price Check（Lodging API）」または「Flight Details （Flight API）」の呼び出しを再度実行し、新しい予約URLトークンを取得してください。その後、予約呼び出しで同じ affiliate_reference_id を使用できます。
応答の例 :
{
"type": "price_mismatch",
"message": "Payment amount did not match current price, please check price and try again.",
"fields": [
{
"name": "payments.amount",
"type": "body",
"value": "100.00"
},
{
"name": "price.amount",
"type": "body",
"value": "120.00"
}
]
}410 - Gone or sold out
Rapid APIのリンクの有効期限が切れている場合、またはリクエストされた在庫が利用できなくなった場合に、この値を返します。
多くのサプライヤーは、Expedia Groupとリアルタイムで直接かつ同期した通信リンクを確立しています。
同期通信による予約とは、当社が管理する提供されたサプライヤーデータに対して、「ショッピングの空き状況および価格確認（Lodging API）」または「フライト詳細（Flight API）」の呼び出しが行われることを指します。このエラーは、ご予約の選択内容に対して在庫が不足している場合に発生します。
これは一時的な状況である可能性があり、再度お試しいただければ在庫が確保できるかもしれません。90 秒待機してから、予約と一緒に送信された同じ affiliate_reference_id を使用して、Retrieve リクエストで予約のステータスを確認します。予約が見つからない場合、旅行者は別の選択肢を選ばなければならない可能性があります。
サプライヤーへの接続状態が悪化している場合にも、「売り切れ」のエラーメッセージが表示されることがあります。その場合、実際の在庫状況については何の手がかりもありません。
応答の例 :
有効期限切れのリンク :
{
"type": "link.expired",
"message": "The link you followed has expired. Please request a new link."
}満室 :
"type": "rooms_unavailable",
"message": "One or more requested rooms are unavailable."426 - Upgrade required
リクエストで、Secure Sockets Layer（SSL）に代わる暗号化プロトコルであるTransport Layer Security（TLS）が使用されていなかった場合、この値を返します。
応答の例 :
{
"type": "upgrade_required",
"message": "This service requires the use of TLS."
}429 - Rate limit error
リクエスト数がレート制限を超えた場合は 429 ステータスコードが返されます。各リクエストは 2 つの異なるレート制限に従います。統合が制限値を超える割合でリクエストを送信している場合のレート制限と、Expedia Group サーバーが制限値を超える負荷を処理している場合のレート制限です。
Expedia Group APIへのリクエストを行う際、受信側のサーバーは、リクエスト数が制限範囲内であるかどうかを確認します。リクエスト数が制限値内であればそのリクエストは処理され、クライアント用のカウントが増加します。クライアントのリクエスト数が制限値を超える場合、サーバーは HTTP 429 (リクエスト過多) のステータスコードを含めた応答を返します。
サーバーでは必要に応じて Rate-Limit-Day-Reset ヘッダーと Rate-Limit-Minute-Reset ヘッダーを含めることができます。これには、次のリクエストを送信するまでの待機時間が示されます。これらは、次のタンブルが発生する時のタイムスタンプで、単位はマイクロ秒 (ミリ秒ではありません) です。
たとえば、日付 / 時刻に変換すると、値「15489792000000」は Friday, February 1, 2019 12:00:00 AM (UTC) となります。
注意 : リクエスト数が多すぎるというエラーが表示された場合は、5 分以上待ってから修正したリクエストを試してください。再試行回数が多くなると、キャッシュのタイミングにより失敗を繰り返すことになります。
応答の例 :
HTTP/1.1 429 Too Many Requests
Connection →keep-alive
Content-Length →106
Date →Fri, 01 Feb 2019 06:20:51 GMT
Rate-Limit-Day-Remaining →18
Rate-Limit-Day-Reset →1548979200000
Rate-Limit-Minute-Remaining →0
Rate-Limit-Minute-Reset →1549002000000
Rate-Limit-Reduction-Status →inactive
Server →EAN
Transaction-Id →003224d2-1407-42fe-8bf8-6d74226e7f00500 - Internal server error
Rapid APIまたは上流システム内で発生したエラーに関する情報を返します。特定の操作が指定されている場合は、メッセージフィールドの指示に従ってください。それ以外の場合は、同じ affiliate_reference_id でリクエストをやり直してください。
Rapid API問題を検知した場合はHTTP 500を返しますが、具体的な問題の内容については特定できません。すべてのパートナーの皆様は、Rapid APIをご利用の際、時折コード500の応答が発生することをご承知おきください。
シリアなど、サポートされていない POS が利用されている場合にも HTTP 500 エラーが発生することがあります。
予約の作成または予約のキャンセル以外の API 応答でエラーを受け取り、既知のパフォーマンス低下がない場合は、後でリクエストを再試行してください。再試行する前の最小遅延 (秒) を示す Retry-After ヘッダーが応答に含まれる場合があります。
予約作成時に API 応答でエラーが表示された場合 :
- 90 秒待機してから、予約と一緒に送信された同じ
affiliate_reference_idを使用して、Retrieve リクエストで予約のステータスを確認します。 - 予約が見つからない場合や、引き続き500エラーが表示される場合は、後ほど再度予約をお試しください。
予約をキャンセルした際に、APIのレスポンスで以下のエラーが表示された場合は：
- 90 秒待機してから、既知の
itinerary_idを使用して、Retrieve リクエストで予約のステータスを確認します。 - 予約がキャンセルされない場合、または引き続き500エラーが表示される場合は、しばらくしてから再度キャンセルリクエストをお試しください。
応答の例 :
{
"type": "unknown_internal_error",
"message": "An internal server error has occurred."
}{
"type": "internal_error",
"message": "An internal server error has occurred. Please discard any previously received results in this pagination and restart the pagination from the beginning."
}503 - Service unavailable
HTTP 503エラーは通常、一時的なものであり、Rapid API, またはその下流のサービスが、現在そのリクエストを処理できないことを示しています。これには、一時的な過負荷からプロバイダーとの接続が切断されたことまで、いくつかの原因が考えられます。
「予約の作成」または「予約のキャンセル」以外のAPIレスポンスでこのエラーが発生し、既知のサービス障害がない場合は、しばらく時間を置いてからリクエストを再試行してください。再試行する前の最小遅延 (秒) を示す Retry-After ヘッダーが応答に含まれる場合があります。
予約作成時に API 応答でエラーが表示された場合 :
- 前回の「料金照会（Lodging API）」または「フライト詳細（Flight API）」のレスポンスに含まれる予約リンクは、短時間で有効期限が切れます。最初に試みた際に HTTP 503 エラーを受信した場合は、リンクが失効している可能性があります。新たなリンクを取得して再度予約してください。
- 2 回目の試行で 503 になった場合は、90 秒待機してから、予約と一緒に送信された同じ
affiliate_reference_idを使用して、Retrieve リクエストで予約のステータスを確認します。 - 予約が見つからなかった場合、または引き続き503エラーが表示される場合は、後ほど再度予約をお試しください。
予約をキャンセルした際に、APIのレスポンスで以下のエラーが表示された場合は：
- 90 秒待機してから、既知の
itinerary_idを使用して、Retrieve リクエストで予約のステータスを確認します。 - 予約がキャンセルされない場合、または引き続き503エラーが表示される場合は、しばらくしてから再度キャンセルリクエストを行ってください。
応答の例 :
{
"type": "service_unavailable",
"message": "This service is currently unavailable."
}504 - Gateway time out
HTTP 504エラーは、通常、Rapid APIによるものではなく、クラウドやエッジインフラストラクチャに起因するものであり、トランザクションの処理中にネットワークインフラストラクチャ内のコンポーネント（ロードバランサーなど）で障害が発生したことを示しています。一般的に、これは一時的な現象です。
注： 旅程の作成前または作成後にタイムアウトが発生する可能性がありますので、旅程が作成されたかどうかを必ず確認してください。
HTTP 504（および502）のエラー応答は、Rapid API'sのJSON形式のタイプとメッセージのペアではなく、HTML形式で返されます。これは、これらのエラーがRapid API.
応答の例 :
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
</body>
</html>エラー応答のしきい値レート
独自の閾値を設定するには、409、410、500、503、および504の各レスポンスコードの1日あたりの発生率を測定する必要があります。しきい値を超えた場合は、Rapid APIのサポートまでご連絡ください。
Expedia Group特定の閾値は設定されていません。これは、組織の市場やその他の要因によって異なるためです。特定のエラー応答が発生する原因を特定するには、市場に関する知識が不可欠です。当社の見通しでは、1日または1週間の期間において、予約の電話の最大5～6％がコード50xのエラーにより失敗すると予想されます。
時間が経つにつれて 、ご自身で閾値を算出できるようになるはずです。単に1日あたりの急激な増加だけを見るのではなく、たとえ1日あたりの閾値が5回に設定されていたとしても、例えば5分以内に2回の500エラーが発生した場合は、Rapid APIのサポートに確認した方が良いかもしれません。
ログ
Rapid APIのサポートからリクエスト／レスポンスのログの提供を求められた場合は、以下の情報を提供してください：
- API 応答ヘッダーの
Transaction-Idの値。これは詳しい調査に欠かせないものです。 - API のリクエストログと応答ログの両方。リクエストログには、使用された完全なエンドポイント URL を含める必要があります。返された HTTP コード、完全な応答データ、返されたヘッダーを応答ログに含める必要があります。
point_of_saleパラメーターを指定した Availability API リクエスト、および Availability の応答。これにより、サポート担当者は、使用されているRapid APIのアカウントおよびプロフィールを特定できるようになります。- 各予約リクエストに対する、予約APIリクエストヘッダーおよび認証ヘッダー（APIキー、署名、タイムスタンプを含む）です。
- リクエストログの Booking リクエスト URL とトークン。
- Booking API 呼び出しの後に発行される Itinerary Retrieve (Booking の呼び出しが成功したか失敗したかは無関係)。
JSON のリクエストと応答全体を含めてください。JSON文字列はdouble-quoted, でなければならないため、double-quote文字の前にバックスラッシュのエスケープ文字を付ける必要はありません。
| 正しい JSON コード | 間違った JSON コード |
|---|---|
json "id": "208646250", "status": "available", | json\"id\": \"208646250\", \"status\": \"available\", |
二重引用符を文字列の一部として含める必要がある場合のみ、二重引用符の前にバックスラッシュのエスケープ文字を使用してください。
レスポンスの例 :
"spokenwords": "He said "hello world""注： ログをPDF形式に変換しないでください。Expedia Groupサポート担当者は、ログデータを社内ツールにコピー＆ペーストすることがありますが、PDF形式ではデータに不要な改行文字が追加されてしまいます。
付録
迅速に解決されなかった予約の例
予約確定の例
予約失敗の例
