Hotel Industry Terms & Processes Guide

1. Purpose and audience

Purpose

This guide explains how hotels behave operationally — covering search, pricing, booking, servicing, fees, outages, and claims — as exposed through Travelport TripServices Stays API. It is written in business language for cross-functional teams who work with the API or its outputs, but who are not writing the integration code themselves.

It complements, rather than replaces, the Developer Portal and Swagger documentation. Where this guide explains what happens and why, the Developer Portal and Swagger define the exact request and response structures for developers building the integration.

The three-layer documentation model

Understanding where this guide fits helps you know where to go for different types of questions:

Intended audience

This guide serves two distinct groups: Travelport-internal teams who support, sell, and develop the API; and teams at agency and partner organizations who consume it. Both groups need to understand what the API does and how it behaves, they just come to that question from different directions.

The 'Who Uses This' column below distinguishes where each role typically sits. Many roles exist on both sides and are marked accordingly.

• Travelport — Travelport-internal roles.

• Agency / Partner — roles at agency, TMC, OTA, or corporate booking tool customers.

• Both — roles that exist on both sides and will use this guide in similar ways.

2. Quick role guide

Use this table to go directly to the sections most relevant to your role. If you are at an agency or partner organization, look for your role in the 'Who Uses This' column — most roles appear on both sides of the relationship.

• Travelport — Travelport-internal roles.

• Agency / Partner — roles at agency, TMC, OTA, or corporate booking tool customers.

• Both — roles that exist on both sides and will use this guide in similar ways.

3. Common industry concepts

This section defines the key terms used throughout the guide. Readers already familiar with hotel industry terminology can skip ahead.

Hotel brand

A large hospitality company that manages a collection of hotels, and resorts.

Examples: Marriott, Accor Hotels, Choice Hotels Corporation, Hilton Hotels Corporation.

Hotel chain

The unique identity of a hotel or group of hotels — its name, standards, and guest proposition — which allows chains to cater to different traveler types. Each hotel chain is assigned a two-letter chain code. For example, Marriott brand chains include Autograph Collection (AK) and Courtyard by Marriott (CY). Accor brand chains include Rixos (RX) and Sofitel (SB).

Hotel property

The physical building and location where guests stay. A property can be owned and operated by a chain, or independently owned and operated to the standards of the brand and chain it is affiliated with.

CRS: Central Reservation System

The CRS manages room rates, availability, and inventory and distributes this information across booking channels. All reservations are created, modified, and cancelled in the CRS — it is the central source of reservation truth for a hotel chain. Chains sometimes migrate from one CRS to another. When this happens, Travelport supports the migration by testing and certifying the new workflows and capabilities.

PMS: Property Management System

On-site software that manages the operational day-to-day of a property: reservations management, guest check-in and check-out, room assignment, and folio management. The CRS sends reservation information to both Travelport and the PMS. Because Travelport connects to the CRS, there is no direct visibility into messages passing between the CRS and the PMS, or between chains directly.

Chain switch / swap

A chain switch or swap refers to the process of a hotel property changing its affiliation from one hotel chain to another. This affects how the property is represented, booked, and managed across GDSs, OTAs, and corporate booking tools. HEDNA (Hotel Electronic Distribution Network Association) publishes formal guidelines that govern this process.

When a chain swap occurs at Travelport, the losing chain code is marked inactive, the property is relisted under the new chain code, and existing reservations and cancellations are transferred. Whether those transfers happen seamlessly depends on CRS continuity.

If the reservation system maintains continuity, reservations remain valid after the swap and can be cancelled under the new chain code. If continuity is not maintained, reservations may not be recognized under the new code and may need to be handled manually by the property or the original booking channel.

Cancellations

When a booking is cancelled, Travelport sends the cancellation request to the chain's CRS. If successful, a cancellation number is returned. In some scenarios the cancel may not process immediately, Travelport will retry. It can take up to four hours for the hotel to return confirmation of success or failure. Travel counsellors using the GDS validate successful cancellations by checking remarks and PNR history.

If a cancellation number is not returned after retries, it is recommended that the traveler or agent contact the hotel directly. Common reasons for cancellation failures include hotel system unavailability, request timeouts, send failures, active CRS migrations, and chain swap transitions where cancellations have not been transferred correctly.

If a customer is charged a no-show fee due to a hotel cancellation error, a refund claim can be submitted. Refunds can take up to three months for the chain or property to process.

4. The hotel booking lifecycle

Understanding the sequence of steps in a hotel booking helps explain why certain things must happen in a specific order, and why shortcuts create problems downstream.

5. How agencies and CBTs manage negotiated rates

Corporate booking tools, travel management companies, and agencies manage negotiated hotel rates through commercial contracts and distribution setup in the hotel's reservation systems. When rates need to be created, updated, or corrected, the process follows two stages: initial loading and ongoing maintenance.

Loading negotiated rates

Contract negotiation and structure

The hotel negotiates directly with the corporation, agency, or group. Depending on the hotel's structure, rates are loaded either by the chain's central office, the individual property, or a third-party representation company that manages independent hotels. Contracts define room types, blackout dates, included amenities, cancellation rules, and the rate access code, typically a three to six character alphanumeric string.

Contract execution and rate code assignment

Once the contract is signed, the hotel assigns or requests a corporate rate code. If the hotel or chain already has a code established in its CRS, that code is reused. If not, the property requests creation of a new access code through its central reservations team or representation partner. The CRS team will not activate the rate without a signed agreement.

Distribution system loading

The hotel's CRS or central office loads the rate plan and rate access code into connected distribution systems, including GDSs and channel managers. The code ensures that only authorized agencies or corporate IDs can view and book the negotiated rates.

Verification and testing

Within a few business days of loading, the agency or CBT should test rate visibility by searching the property using the agreed rate access code across multiple stay dates to confirm availability. If the rate is not visible, the agency should contact the hotel to verify that the CRS update was completed, the rate access code was properly linked to the corporate ID, and the property has submitted the code for activation in connected systems.

Editing or correcting negotiated rates

When a negotiated rate appears incorrectly — wrong pricing, missing inclusions, or unavailable dates — agencies and CBTs follow a collaborative correction workflow:

• Identify the issue. Confirm whether the error originates from the hotel's rate setup (CRS mis-entry, expired rate, missing corporate code) or from the booking platform's mapping or caching.

• Hotel rate correction. The hotel revenue or distribution team corrects the rate plan in the CRS. Updated data automatically flows to all connected systems.

• Agency verification. The agency or CBT refreshes cached data and retests rate retrieval. If discrepancies persist, both sides coordinate a technical validation — checking that rate codes match, the property is active, and corporate IDs are linked.

Escalation and support resources

When rate issues cannot be resolved through standard verification, properties should follow this escalation path:

1. Individual properties contact their chain's central headquarters or distribution support team.

2. Hotel chains and brands access MyTravelport: a self-service platform for managing distribution issues, to raise and track cases.

3. If the chain cannot resolve the issue internally, they raise a case to Travelport through MyTravelport with full details of the rate loading problem.

MyTravelport provides case submission and tracking for technical issues, chain-level user management, proactive alerts and advisories, and a searchable knowledge base for common distribution questions.

6. Master Rate Codes

What is a Master Rate Code?

A Master Rate Code is a single access code that acts as a shortcut to a collection of negotiated rate codes. Rather than submitting each negotiated code individually, an agency or corporate booking tool can pass one Master Rate Code and the Travelport API resolves it behind the scenes into all the underlying rates that have been mapped to it.

This is particularly useful for large customers who have negotiated rates across multiple hotel chains and want to simplify how those rates are requested at search time — without maintaining a long list of individual codes in every booking request.

Master Rate Code vs. Standard Rate Code

The two types of rate code behave differently and must be submitted in separate, dedicated fields:

How Master Rate Code resolution works

When the API receives a request containing a Master Rate Code, it performs the following steps before sending the search to the hotel supplier:

• Expand: The Master Rate Code is looked up and expanded to its associated negotiated rate access codes — up to twelve.

• Filter: Only those component codes linked to the hotel chain in the request are selected.

• Append: The selected codes are added to the outbound supplier message.

• Return: Rate results come back as though each underlying code had been explicitly requested.

This process is invisible to the end user. From the traveler's perspective, they simply see the negotiated rates they are entitled to.

Key rules and limits

v11 and v12 — Where to submit the code

Common errors

7. Hotel loyalty

What is hotel loyalty?

Hotel loyalty programs — also called rewards or frequent guest programs — are free membership schemes run by hotel chains to encourage guests to return to their properties rather than booking with competitors. They are, in broad terms, the hotel industry equivalent of airline frequent flyer programs.

Guests join for free, earn points on qualifying stays, progress through membership tiers as they accumulate nights or spend, and redeem points for free nights, upgrades, airline miles, and other rewards. Higher tiers unlock better benefits: room upgrades, lounge access, complimentary breakfast, late check-out, and bonus point multipliers.

The four largest hotel groups each operate a global program with hundreds of millions of members between them:

Loyalty rates vs. loyalty benefits

These are two distinct things that loyalty programs provide, and they are handled differently in the booking process:

Why this matters for agencies and booking tools

• Rate completeness. If a traveler's loyalty card is not included in the search request, loyalty rates will not be returned for Hilton, IHG, Marriott, or Hyatt. The availability results will be missing an entire category of inventory the traveler is entitled to — and that the hotel's own website would show.

• Booking success. A loyalty rate booked without the card number in the reservation request will be rejected by the supplier. This creates a failed booking after the traveler has already selected a rate. Reading the loyalty requirement indicator correctly and enforcing card presence before the booking call prevents this entirely.

• Traveler trust. Business travelers are highly aware of their loyalty status and point balances. Passing card details correctly, surfacing loyalty rates clearly, and confirming point accrual where available are all factors that drive repeat use of a platform.

How loyalty rates are retrieved

Most major hotel chains do not expose loyalty rates through standard availability channels. They require a specific negotiated rate code to be present in the search request before including loyalty-priced inventory in the response.

Hotel Search Complete handles this automatically. When a search request includes a traveler's hotel loyalty card for a recognised chain, Search Complete appends the appropriate supplier-specific negotiated rate code to the availability request sent to that chain. This happens behind the scenes — there is no need to know or manage those codes directly.

Supported chains

The following hotel chains have automatic loyalty rate handling in Hotel Search Complete:

Loyalty indicators in rate responses

Rate responses include two indicators that are frequently confused with each other. They serve entirely different purposes and should be read independently.

Loyalty ID required at reservation. This indicator is set by Search Complete's own processing logic — not by the hotel supplier. When true, Search Complete has matched the returned rate against a supplier-specific loyalty negotiated code, confirming it is a loyalty fare. The traveler's loyalty card number must be included in the booking request, or the supplier will reject the reservation.

When false, this is a definitive signal — not an absence of data. It means the rate has been checked and confirmed as not a loyalty fare. Both outcomes carry meaning and should be used actively in display and booking logic.

Rate qualification ID required at check-in. This indicator is unrelated to loyalty programs. When true, it means the rate is restricted to a specific qualifying group — AAA members, government employees, military personnel, or senior citizens. The rate can be booked through the GDS, but the hotel's front desk will require proof of eligibility on arrival. Failure to present the appropriate ID results in the guest being charged the standard room rate.

Loyalty points

Where available, rate responses include an estimated loyalty point accrual figure — the number of points the guest will earn by booking that rate. This field is populated only where the hotel supplier provides the data and will not be present on all rates. Point accrual is a common comparison factor for business travelers choosing between similarly-priced options.

Sending loyalty cards in requests

To unlock loyalty rates, the traveler's hotel loyalty card details must be included in the search and rules requests. The loyalty card entry requires the card number and the hotel chain code — for example HH for Hilton Honors or MC for Marriott Bonvoy. The program name and the traveler's current membership tier can also be included where known.

A traveler may belong to multiple hotel loyalty programs. Multiple cards can be included in the same request — one per program. Search Complete handles each chain independently, so including additional cards does not cause errors even if some chains are not represented in the search results.

Booking a loyalty rate

When a rate carries the loyalty required indicator, the loyalty card number must be passed through to the booking request. The supplier validates the card at time of booking — omitting it will result in a supplier rejection.

8. Hotel system outages and service alerts

The CRS manages availability, pricing, and inventory across all channels, while the PMS handles on-property operations. Although modern systems are cloud-based and highly redundant, temporary outages remain a normal part of the hospitality ecosystem.

Types of outages

Travelport service alerts

Travelport issues service alerts when there are disruptions, changes, or planned activities that may impact system performance or user experience. These cover four types of events: 

• System outages or degradations. Unexpected failures in hotel JSON or related systems, performance issues affecting availability or reliability, connectivity problems with suppliers or third-party services.

• Scheduled maintenance. Planned system upgrades or infrastructure changes. Advisory notices are issued in advance so affected teams can plan around them.

• Health monitoring events. Alerts based on internal system health checks and automated detection of anomalies or threshold breaches.

• Advisories and updates. Changes to formats, pricing engines, or configuration. Migration notices (for example, platform transitions). Updates to optional products or applications.

How alerts are communicated

• Service alerts portal — centralized location for viewing current alerts.

• Maintenance advisories — posted ahead of scheduled work.

• System health dashboards — real-time status updates.

• Community forums and knowledge base — may include contextual updates or workaround guidance.

API response during system issues — Quick reference

Support triage — Outage checklist

When a customer reports unexpected availability issues or system behavior, work through the following in order:

1. Check whether a maintenance window or advisory is currently posted on the Service Alerts portal.

2. Retry the request with a reduced scope — narrow the search dates or test a single property to isolate the issue.

3. Compare results against a control market or different chain to determine whether the issue is chain-specific or platform-wide.

4. If escalating, log the correlation IDs and timestamps from the affected requests and attach them to the support case.

9. How hotel chains manage fees

Hotel pricing transparency depends on correctly distinguishing between mandatory regulatory fees and hotel-imposed charges. Both categories appear in rate responses and must be handled differently in display and reconciliation.

Governmental fees

Governmental fees include VAT, city occupancy tax, tourism levies, and environmental surcharges. They are mandated by local law and remitted to authorities. They may be displayed separately or included in the total depending on jurisdictional rules. For example, a hotel in New York City must collect NYC occupancy tax as a governmental fee — this is distinct from a facility fee for gym access, which is hotel-imposed.

Non-governmental fees (hotel-imposed)

These include resort fees, destination fees, facility fees, and service charges. They are intended to cover amenities such as Wi-Fi, gym access, or pool use. They are discretionary, property-specific, and increasingly subject to transparency regulations in various markets.

Disclosure and accounting

Best practice requires all mandatory charges to be disclosed upfront at the time of booking. Optional or property-imposed fees must be clearly noted as payable locally at check-in — not included in the total room rate. CRS and PMS systems store detailed fee structures for taxation, reporting, and audit compliance.

10. CRS migrations

A CRS migration occurs when a hotel chain or property transitions its core reservation infrastructure from one platform to another. These migrations are undertaken to modernise, improve performance, reduce costs, or improve connectivity with other systems. Because the CRS is the system through which inventory, rates, and restrictions flow to all distribution partners, migrations are complex and highly coordinated across the hospitality ecosystem.

Why CRS migrations happen

• Adopt modern, cloud-native architectures that reduce downtime and maintenance overhead.

• Improve integration with new Property Management Systems, Channel Managers, or Revenue Management Systems.

• Consolidate multiple legacy systems after acquisitions or brand unifications.

• Unlock new capabilities such as dynamic pricing, richer content distribution, or improved API connectivity.

How CRS migrations are executed

This is a collaborative process between the hotel and Travelport, typically follows several controlled phases:

• Planning and Data Mapping. The hotel and CRS vendors define how key data — room types, rate plans, taxes, restrictions, negotiated codes — will map between the old and new systems. External distribution partners including GDSs, OTAs, aggregators, and booking tools are notified of the migration window and data change schedule.

• Parallel Operations. For a period, both systems operate simultaneously. Rates and availability are maintained in both to prevent booking disruption. Reservations are synchronized daily or in real time until confidence in the new CRS stabilizes.

• Cutover and Validation. The final cutover redirects live traffic — availability, pricing, booking — to the new CRS. Bookings in the legacy system are imported into the new CRS or remain accessible through archival connectors. Partners test that rates, inventory, and negotiated access codes display correctly.

• Decommissioning. Once confirmed stable, the old CRS is retired. Connectivity with channel managers and distributors is re-established using the new platform credentials and endpoints.

Industry impact

CRS migrations can temporarily affect:

• Rate visibility or synchronization — particularly for negotiated or chain-level corporate rates.

• Booking confirmations — if both systems process reservations during the transition period.

• Content display — if identifiers, such as property codes, room codes, or amenity descriptions, change format.

What this means at Travelport

Travelport works collaboratively with hotel chains throughout the entire migration process — from initial planning and testing through cutover and stabilization. During a migration, customers may see temporary changes in rate availability or confirmation behavior. Travelport will communicate these through the Service Alerts process.

11. Chain swaps

A chain code swap occurs when a hotel or group of properties changes the two-letter code that identifies its brand within a GDS or other distribution platform. This can happen due to rebranding, mergers, CRS transitions, or a change in representation company.  For example, a property operating as a Sheraton (SI) that converts to a Marriott (MC) changes its GDS identifier from SI12345 to MC67890.

How chain code swaps are executed

• Announcement and Coordination. The chain notifies distribution partners of the upcoming change. A cutover date is established and rate access codes, corporate contracts, and property identifiers are mapped to ensure continuity.

• System Preparation. The old chain code remains active during the transition period, often with mirrored rates and availability. The new chain code is provisioned in the GDS and CRS, including rate categories, amenities, and negotiated rate links. Property profiles and room types are copied or remapped.

• Cutover Execution. On the designated date, the property's active inventory, rates, and bookings transfer to the new chain code. Future reservations under the old code are retained and recognized through internal mapping tables. Agencies and CBTs are advised to update saved searches, rate access profiles, and corporate rate lookups to reference the new code.

• Verification and Stabilization. Post-cutover testing ensures that negotiated rates, commissions, and loyalty integrations work as expected. Bookings made prior to the swap continue to be serviced even if the legacy code is no longer visible in searches.

Operational considerations

• Agencies and CBTs: update stored references or templates that point to the old chain code.

• Hotels: maintain both codes in parallel for a short period to avoid disruptions in corporate rate access.

• Distributors: monitor rate parity and mapping consistency to prevent duplicate listings.

12. The hotel claim process

In the hotel industry, a claim is the formal mechanism used to resolve discrepancies between what was contracted or expected and what was actually delivered or charged. Claims can arise between hotels, travel agencies, corporate clients, or distribution partners and may involve rates, commissions, availability, or guest experience issues.

Why claims occur

Typical reasons for claims include:

• Rate Discrepancies. The booked or billed rate differs from the contracted rate, or extra charges not listed in the rate rules appear on the final bill.

• Availability or Overbooking Issues. A confirmed reservation could not be honored due to overbooking or CRS synchronization errors.

• Reservation Not Found. The vendor could not find the reservation at time of arrival despite a confirmation number being issued.

• Content or Amenity Disputes. Amenities or inclusions shown at booking were not honored at that property, often due to feature page discrepancies maintained by the supplier.

• Cancellation Policy Disputes. A cancellation or no-show fee is applied despite the client having cancelled or arrived within policy.

• Billing or Tax Errors. Incorrect charges, double billing, or missing invoice details.

How the industry claim process works

Most hotel claim processes follow five key steps, regardless of brand or distribution network:

Timelines and service levels

13. Travelport hospitality claims process

Travelport's Hospitality Claims team investigates and processes reimbursement requests for incorrect hotel and car charges on behalf of travel agencies and corporate clients. This process is designed to verify system transactions, coordinate with suppliers, and resolve discrepancies where appropriate.

Required steps before filing a claim

Agencies must take the following actions before contacting Travelport's Hospitality Claims team:

1. Contact the provider first. Dispute the charge directly with the local office or head office of the provider. Document all correspondence. Attempt to resolve the issue locally before escalating to Travelport.

2. Gather required documentation.

   • Proof of payment — credit card slip, invoice, or vendor billing

   • Supporting computation — a clear breakdown showing how the claim amount was derived

   • PNR details — locator, hotel/car history, OSIs

   • Reservation evidence — customer email confirmations, booking records

   • Error messages or system anomalies — any logs or screenshots showing issues at point of sell, modify, or cancel

   • Previous case numbers — if raised with Travelport Help Desk previously, include those case numbers

   • Clear explanation — a summary of the claim with justification for why it is valid

3. Documentation standards. All documentation must be in English. Use the correct subject line format:

   • Hotel Claims: TRAVELPORT CLAIM / Guest Name / CF number — Reason of Claim

   • Car Claims: TRAVELPORT CLAIM / Driver Name / CF number — Reason of Claim

Time-sensitive requirements

What Travelport investigates

Travelport accepts and investigates claims in the following circumstances:

• Reservation Not Found — the vendor could not find the reservation at time of guest arrival despite a confirmation number having been issued.

• Cancellation Policy Violations — the cancellation policy present in the GDS booking or rate rules was not respected by the supplier.

• No-Show Fee Disputes — the vendor charged a no-show fee when evidence shows the client did arrive or did cancel correctly.

• Location Discrepancies — booking made at a desired property that belongs to a different establishment not recognized by the supplier.

• Rate Rule Violations — extra charges applied that were not listed in the rate rules displayed at time of booking.

What Travelport does not reimburse

Travelport claims process timeline

Once a properly documented claim is submitted, Travelport will acknowledge within 3 business days. Allow 4–8 weeks for investigation and resolution. The process involves verifying the booking against internal transaction logs, reviewing the timeline of actions taken, coordinating with the supplier where necessary, and processing approved reimbursements or providing a detailed explanation if the claim is denied.

14. Unsolicited cancellations

This section explains what happens when a hotel reservation is cancelled directly with the hotel rather than through the platform where it was originally booked, and why this matters for your integration, your travelers, and your reporting.

What is an unsolicited cancellation?

An unsolicited cancellation occurs when a traveler or agent cancels a hotel reservation directly with the property — by phone, email, or at the front desk — rather than through the platform or system used to make the original booking.

From the hotel's perspective, the reservation may be considered resolved. From Travelport's perspective, no cancellation message was received, and the booking record remains active.

The requirement: Cancel where you booked

All hotel reservations created through the Travelport platform must be cancelled through the Travelport platform. This is both a Travelport requirement and a consistent industry standard applied across all major GDSs and OTAs.

The correct cancellation flow is:

1. The traveler or agent initiates the cancellation through the original booking channel — the booking tool, TMC system, or API call.

2. Travelport sends a cancellation request to the hotel's CRS.

3. The hotel confirms cancellation and returns a cancellation number.

4. The PNR is updated and marked as cancelled in Travelport's system.

Risks of out-of-channel cancellations

When a cancellation is made directly with the hotel and bypasses the booking platform, several downstream problems occur:

• PNR Remains Active. Travelport has no way of knowing the reservation was cancelled. The PNR stays open, appearing as a live booking in all downstream systems.

• Reporting Inaccuracy. Active PNRs feed into occupancy reporting, travel spend analysis, and duty-of-care platforms. A ghost reservation corrupts this data until manually resolved.

• Fee Exposure. Depending on the rate rules, fees including cancellation penalties or no-show charges may still apply if the cancellation was not processed through the original channel. Some properties will not honor a direct cancellation as a waiver of fees.

• Reconciliation Burden. Finance, TMC, and agency teams may need to manually investigate and close out records, increasing operational overhead and the risk of billing disputes.

Best practices for agencies and booking tool partners

• Display a prominent reminder in booking confirmations and itineraries that cancellations must be made through the original booking platform, not directly with the hotel.

• Where possible, accompany hotel contact details in confirmation emails with clear language that direct contact is for emergencies only and does not constitute a formal cancellation.

• Configure pre-trip reminder notifications to reinforce same-channel cancellation policy.

• If a traveler reports they cancelled directly with the hotel, process a cancellation through the platform immediately and note the hotel-issued reference number in the PNR for reconciliation purposes.

Best practices for travelers

• Always cancel hotel reservations using the same booking tool or system used to make the reservation.

• If you contact the hotel directly for any reason — including modifying a stay — do not assume the conversation constitutes a formal cancellation.

• After cancelling, confirm you receive a cancellation number and that your booking portal reflects the updated status before the check-in date.

• In emergency situations where you must cancel directly with the hotel, notify your travel manager or TMC immediately so the booking record can be corrected.

15. Rate Filtering Best Practices

Overview

The rateFilter object is an optional element in the Search Complete request body. It gives you two mechanisms to influence rate results.

How Lowest Filtered Available Rates Work

Each property in the Search Complete response includes the following lowest-rate values:

• lowestAvailableRate – the lowest rate across all rates for the property, with no filtering applied.

• lowestFilteredPublicAvailableRate – the lowest public rate selected from only those rates that meet all active rateFlags criteria.

• lowestFilteredPrivateAvailableRate – the lowest private/negotiated rate selected from only those rates that meet all active rateFlags criteria.

The rateFlags you set determine the candidate pool from which both filtered rate values are drawn. Rates that do not meet the active flags are excluded from candidacy for these values but remain fully visible in the property's rate list.

Understanding Flag Behavior

All flags follow the same core rule: if a flag is explicitly set to true, the corresponding filter is applied. If a flag is set to false or omitted entirely, it is treated identically – the filter is not applied and has no effect on candidacy.

The flags fall into two behavioral types:

• Pair flags (refundable, commissionable, deposit) -- the API evaluates complementary pairs. Setting refundable: true preferences refundable rates. The non-refundable counterpart is evaluated in parallel. False or omit means neither side is applied.

• Single flags (prepay, postpay, breakfast, lunch, dinner) -- only have a filtering effect when set to true. False and omit are equivalent and apply no restriction. Refer to Advanced Purchase for a list of hotel chains that support prepay rates.

rateFlags Reference

The table below summarizes the behavior of each flag. "Pair" flags evaluate complementary rate types; "Single" flags only filter when true.

Flag-by-Flag Guidance

refundable

Setting refundable: true instructs the API to preference a refundable rate when selecting the lowestFilteredPublicAvailableRate and lowestFilteredPrivateAvailableRate. This is a soft preference: if no refundable inventory exists for a property, the API falls back to non-refundable rates rather than returning no result.

Setting refundable: false or omitting the flag produces the same result -- no refundability preference is applied. There is no way to restrict candidacy to non-refundable rates only without a separate nonRefundable flag.

If you need to exclude non-refundable rates from your displayed results entirely, apply client-side filtering on terms.refundable in the response.

commissionable

Setting commissionable: true restricts lowest rate candidacy to commissionable rates only. Like refundable, this is a pair flag -- both commissionable and non-commissionable sides are evaluated.

Setting it to false or omitting it produces the same result: no restriction is applied, and both commissionable and non-commissionable rates candidate equally.

deposit

Follows the same pair flag behavior as commissionable. Setting to true restricts candidacy to deposit rates. False or omit applies no restriction.

prepay

Setting prepay: true restricts lowest rate candidacy to prepay rates only. This is a single flag -- false and omit are equivalent and apply no restriction. Refer to Advanced Purchase for a list of hotel chains that support prepay rates.

postpay

Setting postpay: true restricts lowest rate candidacy to postpay rates only. This is the standard configuration for agency workflows where postpay is the expected settlement model.

breakfast, lunch, dinner

Each meal flag, when set to true, restricts lowest rate candidacy to only rates that include that meal. These are single flags -- false and omit apply no restriction.

The flags are independent of each other and can be combined. Setting more than one to true means the lowestFilteredPublicAvailableRate and lowestFilteredPrivateAvailableRate will only be drawn from rates satisfying all specified meal criteria.

Omit all three if you want rates with and without meal inclusions to remain in candidacy.

publicRateBlacklist

The publicRateBlacklist array accepts up to 5 words or phrases. Any public rate whose description contains a matching string is excluded from lowest rate candidacy and suppressed from the response entirely. This is the only rateFilter mechanism that removes rates from returned results.

Client-Side Filtering

Because rateFlags affect only the filtered lowest rate values and not the full rate list, you may need to apply additional filtering to the response to control which rates are displayed to your users. The following response fields support reliable client-side filtering.

Filtering by refundability

Field: terms.refundable (boolean)

Each rate includes a refundable boolean within its terms object. Filter out any rate where this value is false if you want to display only refundable rates in your results.

Filtering by payment type

Field: terms.ratePaymentInfo (enum: PrePay | PostPay | Unknown)

Each rate includes a ratePaymentInfo value within its terms object, returning one of the following:

• PrePay – the rate must be paid in full at the time of booking.

• PostPay – payment is collected at the property or invoiced after the stay.

• Unknown – the payment type could not be determined from the supplier response.

To exclude prepay rates from your displayed results, filter out any rate where terms.ratePaymentInfo equals "PrePay".

Example Configuration

The following example demonstrates a configuration that:

• Preferences refundable rates for both lowestFilteredPublicAvailableRate and lowestFilteredPrivateAvailableRate (with fallback to non-refundable if needed)

• Restricts filtered lowest rates to postpay rates only

• Applies no restriction on commissionable status, deposit, or meal inclusions

Request: rateFilter

"rateFilter": {
  "rateFlags": {
    "refundable": true,
    "postpay": true
  }
}

Recommended client-side filtering on the response

// Exclude prepay rates from displayed results
rates.filter(rate => rate.terms.ratePaymentInfo !== "PrePay");

// Optionally: exclude non-refundable rates from displayed results
rates.filter(rate => rate.terms.refundable !== false);

16. Chain capabilities

Chains support different content and capabilities at the CRS, switch, and chain level. Where programmatically possible, Travelport manages these differences by normalizing content, providing additional warnings, and adding orchestration logic. The table below reflects capabilities as of 1 October 2025.

Capability descriptions

Hotel chain capability matrix — 1 October 2025

Hotel chain exceptions

Document Feedback

We value your feedback on this documentation. If you have suggestions for improvements, find errors, or need clarification on any topic, please contact:

• Your Travelport Account Manager

• Travelport Support team

• Developer Portal feedback form

For urgent API issues or production support, contact Travelport support immediately.