Skip to main content
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. 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

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

1

Choose Ingestion model

Agree the notification format and whether you’ll process full + delta or delta‑only after initial load.
2

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

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

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

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

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.
If you have questions about which format fits your needs best, or require a custom integration, please contact our integrations team.