Rapid Lodging APIのグローバル在庫を拡大

世界中に在庫を拡大し、世界規模で競争

エクスペディアの拡張グローバルインベントリー（EGI）を利用すれば、世界中の34,000軒以上のホテルと競合することができ、在庫は定期的に追加されます。これには新たに調達する物件と、現在調達している物件の追加在庫が含まれます。

技術詳細

EGIはRapid API, の標準インベントリには含まれていませんが、リクエストに応じて明示的に有効にすることができます。標準的なインベントリとは異なる動的な動作や統合パターンが特徴で、コンテンツの取り込み、ショッピング、予約のワークフロー全体で特別な注意が必要です。

コンテンツファイル

EGIのRapid Content FileおよびCatalog File APIは、現在English-languageコンテンツのみをサポートしています。システムがローカライズされた(non-English) )コンテンツファイルを必要とする場合、施設Content とGeography APIを使ってローカルに生成することができます。これらのAPIは、real-timeストリーミングと、あらゆるコンテンツ言語に対する柔軟なデータ処理を提供し、JSON-formatted APIレスポンスから必要な情報を簡単に抽出することができます。後で処理するために生のJSON応答をローカルに保存したり、データベースインポートやその他のユースケースのために変換したりすることができます。

Geography APIを使って地域のプロパティリストをリクエストする例：

/regions?country_code=US&language= it-IT&include=property_ids_expanded&include=property_ids

施設コンテンツAPIを使ったカタログコンテンツのリクエスト例：

/properties/content?language=it-IT&supply_source=expedia&property_id={property_id}&include=catalog

ショッピングと予約のワークフローを見直すための追加時間を割り当てながら、EGI向けにコンテンツ統合を優先的に開始することもできますし、EGIの準備が整った時点で3つのコンポーネントをまとめて開始することもできます。設定の詳細については、統合コンサルタントにお問い合わせください。

部屋データの調整

あなたのシステムと 施設Content APIが完全に同期される前に、Shopping API に新しい 施設 の部屋が現れるかもしれません。一貫したユーザーエクスペリエンスを維持するには、これらのルームを一時的に顧客表示から除外するか、新しいルームのreal-time Content API呼び出しをトリガーするか、またはローカルコンテンツの更新頻度を増やしてデータの遅延を最小限に抑えることを検討してください。

レート識別子

EGIレートは標準的なインベントリーとは異なる構造になっており、よりダイナミックなデータモデルに準拠しています。これらのレートには静的な値がないため、ショッピングAPIは施設コンテンツAPIの値とは対応しない動的なrate_id。この動的な文字列値は、数字、文字、およびその他のさまざまな記号で構成され、ショッピングAPIレスポンスごとに異なる場合があります。このため、rate_id の値は不安定であり、永続識別子や主キーとして使用すべきではありません。システムでプロセス間のレートを区別する必要がある場合は、ポリシー属性とオファー特性の組み合わせでレートを照合することを検討してください。詳細については、この保護された文書 を参照してください。

Shopping APIレスポンスのrate_id値の例：

[
  {
    "property_id": "ABC152",
    "status": "available",
    "rooms": [
      {
        "id": "XYZ652",
        "room_name": " Deluxe Double ",
        "rates": [
          {
            "id": "5K|Pa7xbx4z||GCogh8-B96OEY3-f9326e292|UFO",
            … …

ベッド構成のばらつき

例外的な状況において、特定の客室には指定されたベッド構成がない場合があります。この場合、コンテンツとショッピングの両方のAPIにおいて、bed_groups IDが0であることと、"ベッドが指定されていない "という説明で示されます。これは、施設がベッドの配置を決定することを意味します。check-in. このような事態が発生することは稀ですが、お客様のシステムはお客様に常に情報を提供し、強いご希望がある場合は、特別なご要望をカスタマーオペレーションチームに伝えるお手伝いをする必要があります。

Shopping APIレスポンスに含まれる未指定のベッド設定の例：

{
  "bed_groups": {
    "0": {
      "id": "0",
      "description": "Bed Not Specified",
      "links": {
        "price_check": {
          … …

Hold と Resume 機能

一部のEGIレートは、Booking APIHold and Resume ワークフローと互換性がなく、保留が試みられるとエラーを返します。カスタマーエクスペリエンスの低下を防ぐために、ショッピングAPIのレスポンスでホールドレートフラグをリクエストし、それに従って正しいワークフローを適用することができます。

保持率フラグの要求例：

Request:
/properties/availability?... …&include=rooms.rates.holdable

Response:
… …
"rooms": [
  {
    "id": "XYZ652",
    "room_name": "Deluxe Double Room",
    "rates": [
      {
        "id": "5K|Pa7xbx4z||GCogh8-B96OEY3-f9326e292|UFO",
        “holdable”: true,
        … …

Post-booking特徴

Booking APIを通じて予約が確認されると、予約はManage Booking APIs に配信されます。ソフトチェンジ、ハードチェンジ、施設メッセージセンターなど、post-bookingの機能にアクセスするためのトークン・リンクも、予約管理APIで利用できるようになります。トークン・リンクの準備に5分ほどかかることがあります。これらの機能はすべての予約で利用できるわけではなく、システム内で優雅に管理する必要があることに注意することが重要です。

EGIの主な違い