共通エラー応答
当社の API サービスは、次に示すエラーコード、エラーメッセージ、エラー応答のフォーマットを共有しています。
Rapid でのエラー処理に関する推奨事項
エラー処理ロジック
- プラットフォームとパートナーは、ショッピングと予約APIのエラーを処理するために、エラー処理ロジックが配置されていることを確認する必要があります。
- 以下の注意事項で指定されていない限り、すべての予約リクエストで必ず一意の
affiliate_reference_idを使用してください。 - 特に予約リクエストのエラー処理ロジックは常に見直し、更新する必要があります。
- すべてのRapid APIレスポンスには、対応するHTTPコードがあります。レスポンスHTTPコードの一覧については、以下を参照してください。
接続タイムアウトまたは通信タイムアウト
フライトAPIブッキングリクエストには120秒のAPI接続タイムアウト設定を推奨します。ただし、ショッピング・アベイラビリティ・コールの接続タイムアウトを小さくすることもできます。
120秒経っても応答がない場合、Rapid API's自身の接続タイムアウトが120秒に設定されているため、Rapid APIは5xxエラーを発行します。
場合によっては、Rapid APIはHTTP Expect: 100-Continue プロセスをサポートしていません。特に、cURL、C#/.NET、およびデフォルトでこのプロセスに従う他のいくつかのコーディング言語では、このプロセスでサーバーに接続しようとすると、接続の問題が発生する可能性があります。
注 : HTTP 504 のゲートウェイタイムアウトが発生しても、Rapidでタイムアウトが発生したというわけではありません。このような場合、インフラ・サービスに障害が発生したか、Rapidが別のダウンストリーム・サービスのゲートウェイとして動作しており、そのサービスのタイムアウト制限を設定しています。ダウンストリームのタイムアウトは504としてトリガーされます。504がブッキングコールで発生した場合、ブッキングが作成される前（ホテル通信、支払いサーバー）または作成後（Expedia Group財務管理）に下流の問題が発生した可能性があるため、旅程検索（affiliate_reference_id+ Eメール）を使用してブッキングが作成されたかどうかを確認してください。また、インターネット接続が安定していることも確認してください。Traceroute コマンドで接続の問題を特定できる場合もあります。
予約と取得 5xx エラーの処理
予約エラー（5xxステータス）またはタイムアウトは、必ずしも予約自体が無効であることを意味するものではありません。予約が作成された後にエラーが発生した可能性があります。予約状況を確認するために、affiliate_reference_id+ Eメールでの旅程検索を発行することをお勧めします。
90秒以内に返されたエラーは、予約の最終的なステータスを示すものではありません。通常、ほとんどの予約は13-30秒以内に予約確定となりますが、中には予約確定に5分かかるものもあります。
90秒間に3回予約状況をチェックするロジックを実装することができます。ほとんどの応答は最初の30秒以内に確認され、90秒を待たずに応答を確認することができます。最終的な回答が得られなかった場合、Rapid APIコールセンター・エージェントにさらなるサポートを依頼する前に、30分間検索を再試行することができます。
予約結果（HTTP 200またはHTTP 404レスポンス）をdouble-confirm、Retrieve APIコールを使用します。
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ヘッダーに問題があることを示しています。エラーレスポンスは、予約リクエストヘッダの実際の無効なエラー配列フィールドを含みます。ヘッダーは、部屋や支払いなど、いくつかの配列と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 Key + 共有シークレット + UNIXタイムスタンプ(秒)を連結したSHA-512ハッシュ** (**unsalted) を含む必要があります。詳細については、シグネチャー認証のページを参照してください。
Lodging API 401 unauthorizedレスポンスの例：
{
"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 principal JSON web token (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 も、要求されたgeographyやcontent-specificファイルやリソースが見つからない場合に、404レスポンスを使用します。詳しい例については、それぞれの文書ページを参照してください。
Itinerary Retrieve の後のコード 404 は、予約が見つからなかったことを示します。予約エラーのために取得が行われた場合、予約が作成されなかったと表示されます。ただし、Itinerary Retrieve APIリクエストパラメータが有効であることを確認する必要があるため、Retrieveaffiliate_reference_id、Eメール、旅程番号が正しいことを確認してください。また、Retrieve API呼び出しが予約呼び出しから90秒未満に行われた場合は、再度取得を試みることをお勧めします。
応答の例 :
{
"type": "resource.not_found",
"message": "The requested resource could not be found."
}409 - Price mismatch
多くのサプライヤーがダイナミック・プライシング、いわゆる「time-basedプライシング」を採用しています。そのため、需要と供給のアルゴリズムに基づいて価格が変動します。Expedia Groupレートは1秒間に何度も更新されるため、レートは頻繁に変わります。
重要なことは、これは通常、サプライヤーが選択することであり、むしろ、サプライヤーが選択することではないということです。Expedia Group. さらに、料金と空室状況には複数のレベルでキャッシュがあるため、予約には何層もの待ち時間が発生する可能性があります。
価格の不一致（PMM）は予想される事態であり、システムの劣化や更新された価格が反映されないシステムなど、さまざまな理由で起こり得ます。これらのイベントの頻度を監視し、レートが突然上昇したり、しきい値に達した場合は、サポートに連絡してください。
同時に複数の結果でPMMが発生した場合は、Rapidの劣化の可能性をチェックする必要があります。
もし、PMMが長期間にわたって同じ結果で返されるのであれば、それはおそらくサプライヤーがレートを正しくロードしていないことが原因でしょう。テクニカルサポートにお問い合わせください。
PMMから復旧するには、再度Price Check (Lodging API)またはFlight Details (Flight API)をコールし、新しいBooking 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
リクエストがSSL (Secure Sockets Layer) に代わる暗号プロトコルであるTLS (Transport Layer Security) を使用していなかった場合に返されます。
応答の例 :
{
"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 応答でエラーが表示された場合 :
- 前回のPrice Check (Lodging API)またはFlight Details (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。閾値を超えた場合は、Rapid APIサポートまでご連絡ください。
Expedia Group閾値は、組織の市場やその他の要因によって異なるため、設定された閾値はありません。なぜエラー反応が起こるのかを判断するには、市場の知識が不可欠です。当社のガイダンスでは、1日または1週間で、予約コールの最大5～6％がコード50xエラーで失敗すると予想しています。
時間が経てば、自分で閾値を計算できるようになるはずです。1日に5回としきい値が設定されていても、例えば5分以内に2回500エラーが発生した場合は、Rapid APIサポートに確認する必要があります。
ログ
Rapid APIサポートからリクエスト/レスポンスログの提出を求められた場合は、以下のものを提出するようにしてください：
- API 応答ヘッダーの
Transaction-Idの値。これは詳しい調査に欠かせないものです。 - API のリクエストログと応答ログの両方。リクエストログには、使用された完全なエンドポイント URL を含める必要があります。返された HTTP コード、完全な応答データ、返されたヘッダーを応答ログに含める必要があります。
point_of_saleパラメーターを指定した Availability API リクエスト、および Availability の応答。これにより、サポートは使用されているRapid APIアカウントとプロファイルを特定することができます。- 各予約リクエストの予約APIリクエストヘッダと認可ヘッダ（APIKey、署名、タイムスタンプを含む）。
- リクエストログの 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形式ではデータに不要な行文字が追加されます。
付録
すぐに解決しなかった予約例
予約確定例
予約の失敗例
