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

# Introduction

Please check this overview of all supported notification formats for distributing hotel, excursion, and transfer data to partners and clients.

Our notification ecosystem is designed to support a wide range of integration needs, from real-time transactional flows to high-volume cache files and static content updates. All formats are designed for automation, reliability, and compatibility with industry standards.

***

## Examples

An example for every of our formats is available at [Resources](../resources/downloadables#notification-examples). The examples can be useful to see how our message is implemented, which components from the official schemas are mostly used, etc. If more detailed examples are needed, contact Integrations.

The examples produced are all for the same hotel, transfer and tour activity.

They contain the most common scenarios for a contract:

* Base rates.
* Extras & Offers.
* Board and Pax Supplements.
* Rate Overrides.
* Open and closed allotments.
* Min stay, release and other rules.

## Common Information

* **Push Model**: Most notifications are delivered as push files (via FTP/SFTP), either as full data sets or as deltas (incremental updates).
* **Notification Frequency**: Full notifications are typically sent weekly or monthly; deltas can be as frequent as every 15 minutes.
* **Customization**: Many formats allow for client-specific tailoring (e.g., FlatFile, EDF).
* **Static Content**: Non-bookable content (NBC) and static product descriptions can be pushed in the same structure as transactional messages.
* **Specifications and Schemas**: OTA, EDF and OTDS notifications are based on the official formats. Check [Specifications and Schemas](../glossary/specs)

***

## Supported Notification Formats

### **OTA Notifications**

* **Hotel** and **Excursion** support.
* Message/Files used: `OTA_HotelInvNotifRQ/RS`, `OTA_HotelAvailNotifRQ/RS`, `OTA_HotelRatePlanNotifRQ/RS`, `OTA_TourActivityAvailRQ/RS`, `OTA_TourActivityBookRQ/RS`.
* Supports full and delta updates for inventory, rates, and availability.
* Static content and NBC can be pushed in the same XML structure as transactional messages.

### **EDF**

* Developed by Peakwork for hotel data.
* Highly structured XML for inventory, rates, and allotment.
* Includes DRV GlobalTypes for standardized product attributes.
* Supports both full and delta notifications.

### **OTDS**

* XML-based, developed by OTDS Verein.
* Used for hotel data (rates, inventory, allotment).
* Supports full and delta notifications.

### **FlatFile Notifications**

* High-volume, line-based cache files for hotel inventory, rates, and allotment.
* Multiple versions (with/without RatePlans, extended code lengths).
* Fully technical, with detailed field grids and parameterization.
* Ideal for advertising systems and large-scale cache/search solutions.
* Not rule-based.

### **TransferEDF**

* Proprietary Peakwork format for distributing transfer product data.
* Structured similarly to other EDF notifications.
* Contact us for details and integration options.

***

## Additional Capabilities

* **Static Content & NBC Push**: Receive static product descriptions and non-bookable content in the same format as transactional messages, delivered as notifications.
* **Packaging Support**: All major formats support both pre-packaged and dynamic packaging models.
* **Brand/Partner Customization**: Many formats allow for brand-specific rates, policies, and content.

***

## Notification Cadence

* **Full Notifications**: complete data sets (e.g., all inventories/rates/availabilities) for an agreed future window (commonly **12–18 months**).
* **Delta Notifications**: only the changes since the last full set—for example, stock changes for affected dates or updated rates for an affected property/season.
* **Typical Schedule**: full sets no more than **once per week** (often monthly); **deltas every 15 minutes** during daytime and **hourly overnight** (CET).

### Delta Deliveries

Deltas are sent on top of the last full baseline and must be **applied in order of reception** to achieve the correct end state.

***

## Suggested Implementation Steps

<Steps>
  <Step title="Choose Ingestion model">
    Agree the **notification format** and whether you’ll process **full + delta** or **delta‑only** after initial load.
  </Step>

  <Step title="Map Properties & Products">
    Map hotels, rooms, boards, and extras from inventory notifications and (optionally) descriptive content pulls. Avoid hard‑coding assumptions; re‑evaluate selections when a delta sends a **full snapshot** for a property.
  </Step>

  <Step title="Apply Availability Updates Correctly">
    Treat the latest **baseline** as ground truth and **apply deltas in order**. Stop‑sales may appear in baseline as undated closes while they persist.
  </Step>

  <Step title="Respect Booking Rules & Price Logic">
    Use notifications for **price guidance** only. Validate **final price & stock** via real‑time booking before you confirm or collect payment.
  </Step>

  <Step title="Handle Deactivations & Removals">
    A **deactivated rateplan** usually means no future contract is currently active (keep your mapping). A **deactivated inventory** means the property left your portfolio (remove only if agreed with your PM).
  </Step>
</Steps>

***

## Getting Started

* Review the dedicated pages for each format for technical details, message structures, and integration tips.
* For static content and NBC, see the dedicated static content push page.

<Info>
  If you have questions about which format fits your needs best, or require a custom integration, please contact our integrations team.
</Info>