> ## Documentation Index
> Fetch the complete documentation index at: https://docs.axisdata.net/llms.txt
> Use this file to discover all available pages before exploring further.

# OTA

This page summarizes how Axis Data’s **OTA-based notifications** work in a push model.

## Introduction

Axis Data supports a **push** integration where product changes are delivered to partners using standard **OpenTravel Alliance (OTA)** messages. The OTA spec is maintained by OpenTravel and is updated twice per year ("A" and "B" releases).

<Tip>
  Useful reference: OpenTravel’s Model Viewer and schemas are available from the OpenTravel website.
</Tip>

Whenever you see protocol/message names or field-level details, treat them as pointers and **Check official documentation**.

## Message Types

### Inventory

**Purpose**

Gives the partner a clear picture of **what a property sells**: room types, board types, extras, amenities and descriptive content used for mapping and display.

**Delivery Process**

* Sent as notifications per property, both for initial load and when updates occur. Many partners still receive a daily full set; **delta inventory** is recommended so you only process what changed.
* When anything in the property’s contracted services changes (rooms, boards, extras, occupancy periods, amenities), a **delta** may push a **full inventory snapshot for that property** so you can re‑evaluate what to keep on sale.

**Essentials**

* **Rooms, Boards, Extras, Amenities** are the core groupings you’ll map on your side.
* **Non‑refundable rooms** are explicitly indicated and should be flagged in your UI/UX.
* **Occupancy rules** (e.g., age ranges, total occupancy, excluded combinations) exist per period; infants may or may not count depending on the contract.
* **Extras payable on arrival** (tourist taxes, safe boxes, heating, etc.) may be listed with amounts and whether they are obligatory or optional; these are **not** included in price and must be shown as information.
* **Deactivated** inventory indicates a property is removed from the partner portfolio (permanent removal on your side only if agreed).
* **Car packages**: Some rooms include a car; the hotel code may include a two‑letter extension (e.g., **AR**) and a **car inventory code** may be present.

**Content Pull Option**

* You can optionally pull non‑bookable content via **Hotel/Product Descriptive Info** and/or receive periodic pushes (full monthly + daily deltas) in agreed languages.

### Allotment

**Purpose**

Communicates **when** each room/board combination is open, closed, on request, or free‑sale, either over **date ranges** or **day‑by‑day**.

**Availability Logic**

* Two models, **range‑based open/close** or **per‑day remaining allotment** are using standard codes (e.g., on‑request, stop‑sale, free‑sale).
* Availability can be tracked at **room + base board** level; if you cannot handle this combination, AxisData can send a simplified status at room level only.
* **Stop‑sale by board** is possible either across all rooms or for specific rooms.

**Delta Behavior**

* Messages distinguish **baseline** vs **incremental** updates; deltas overlay the last baseline. A persistent **stop‑sale** may be reflected in baseline as a general close without dates. Apply deltas **in order** to get the final picture.

**Also Supported**

* **Car packages** can be controlled here too via inventory block codes.

### Rates

**Purpose & Important Caveat**

Rateplan notifications provide **price guidance** and rules (booking windows, LOS, supplements, offers), primarily for **packagers** who need prices to build packages and manage product. **Only the real‑time booking response is authoritative for availability and final payable amount**. Partners must not commit to fixed selling prices based on notifications or searches.

<Warning>
  Treat rate notifications as **informational**. Validate at booking time before confirming to customers.
</Warning>

**Rateplan Breakdown (High Level)**

* **Basic rates** for the product (usually a room type + board) over defined seasons/periods.
* **Booking rules** like minimum stays, closed arrivals/departures, and selling windows.
* **Supplements & extras** such as additional adults/children, board upgrades, gala dinners, or per‑stay/per‑person charges.
* **Promotional offers** (e.g., early booking discounts, free nights, upgrades), with compatibility rules and application order.
* **Deactivation**: Empty rate plans can signal a property going temporarily off‑sale; keep mapping, expect future rates.

**Important Identifiers**

* **Room code + RatePlan code combined** (e.g., `roomcode;rateplancode`) may appear in notifications and real‑time messages.
* **InvCode** (room + base board) helps detect included board in the base rate.

**Special Cases**

* **Rate overrides** can temporarily supersede base rates for defined booking/arrival windows.
* **Application units** (per person/night, per room/stay, per week, etc.) exist for both extras and offers.
* **Car packages** (rooms including a car) can be priced via extras/supplements or controlled as inventory blocks.

## Common Scenarios & Tips

* **Rooms with different base boards by season** (e.g., HB instead of BB in high season). Expect search/price responses to reflect what’s actually sold in that period.
* **Non‑refundable rooms** should be clearly labeled in your UI and excluded from flexible cancellation logic.
* **Extras payable on arrival**: Show these transparently; do not bake them into package prices.
* **Day‑by‑day allotment**: On‑request, stop‑sale, and free‑sale are standard states—make sure your search UX reflects them.

***

### Message Names (Reference)

* Inventory: **OTA\_HotelInvNotifRQ/RS**
* Allotment: **OTA\_HotelAvailNotifRQ/RS**
* Rates: **OTA\_HotelRatePlanNotifRQ/RS**