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). 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. 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