Rapid Lodging API 的全球庫存範圍已擴大

透過全球各地擴充的庫存，在全球範圍內展開競爭

Expedia 擴展全球房源庫 (EGI) 能協助您與全球超過 34,000 家住宿設施競爭，且房源數量正持續增加。這包括新取得的不動產，以及目前已取得的不動產中的新增庫存。

技術細節

EGI 並非 Rapid API, 中的標準套件，但可應要求明確啟用。其動態行為與整合模式有別於標準庫存系統，因此在內容導入、購物及預訂工作流程中，皆需特別留意。

內容檔案

EGI 的 Rapid Content File 和 Catalog File API 目前僅支援 English-language 上的內容。如果您的系統需要本地化 (non-English)) 的內容檔案，您可以使用旅宿內容與地理 API 在本地端生成這些檔案。這些 API 提供 real-time 串流功能，並能靈活處理所有內容語言，讓您能輕鬆從 JSON-formatted API 的回應中擷取所需資訊。您可以將原始 JSON 回應儲存於本地端，以便日後處理；或對其進行轉換，以供匯入資料庫或其他用途。

>> 瞭解 Content API
>> 閱讀關於 Geography API 的資訊

以下是使用 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 做好準備時，也可以將這三個組件一併推出。有關設定的詳細資訊，請聯絡您的整合顧問。

客房資料對齊

在您的系統與旅宿內容 API 完全同步之前，新的旅宿房間可能會先出現在購物 API 中。為維持一致的使用者體驗，請考慮暫時將這些房間從客戶端顯示中排除、觸發針對新客房的 real-time 內容 API 呼叫，或是提高本地內容更新的頻率，以盡量減少資料滯後。

>> 了解「購物 API」

費率識別碼

EGI 的定價結構與標準庫存不同，並採用更具動態性的資料模型。由於這些費率沒有固定數值，Shopping API 會以動態的「rate_id」值回傳，該值與旅宿 Content API 中的數值並不對應。此動態字串值由數字、字母及各種其他符號組成，且在每個 Shopping 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 和「購物」API 中，透過bed_groups ID 為 0 以及描述「床位未指定」來標示。這意味著旅宿將決定床鋪的安排方式，當 check-in. 雖然這種情況較為罕見，但貴系統仍應持續向客戶提供相關資訊；若客戶有明確偏好，則應協助其向我們的客戶營運團隊提出特殊要求。

購物 API 回應中未指定床型配置的範例：

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

保留和復原

某些 EGI 費率與「預訂 API」的「暫停」與「恢復」工作流程不相容，若嘗試執行暫停操作，將會返回錯誤。為避免造成不良的客戶體驗，您可以在 Shopping 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 特色

透過「預訂 API」確認預訂後，該預訂資訊將傳送至「管理預訂 API」。用於存取 post-booking 各項功能 (包括「軟變更」、「硬變更」以及旅宿訊息中心) 的代碼連結，也將在「管理預訂」API 中提供。有時，代幣連結可能需要長達五分鐘才能準備就緒。請特別注意，這些功能並非適用於所有預訂，應在您的系統中妥善處理。

>> 了解「管理預訂」API

EGI 的主要差異