Discounts and rates

v3.2 v3.3

Learn about the discounts and rates available through the Demand API and how to retrieve the right prices for each traveller.

Booking.com supports different types of discounts and rates based on factors such as booking dates, traveller location, platform, authentication status and partner configuration.

You can use the Demand API to retrieve:

• Deals — Promotional discounts, including seasonal and time-sensitive offers.
• Target rates — Rates for travellers using a specific platform or booking from a specific location.
• Closed user group (CUG) rates — Exclusive rates for eligible authenticated travellers.
• Third-party inventory (TPI) rates — Rates sourced from external suppliers.

The Demand API supports several discount mechanisms. Each type has a distinct business purpose and API behaviour.

Deals are promotional discounts offered for eligible products. Depending on the deal, eligibility can be determined by factors such as authentication status, booking dates, promotional campaigns or other applicable conditions.

Use cases include:

• Promoting time-sensitive campaigns, such as Black Friday or flash deals.
• Highlighting products during specific promotional periods.
• Offering discounts based on when a traveller searches or books.
• Driving short-term bookings through targeted promotions.

The Demand API identifies applicable deals through the products.deal object.

Examples of deals available through the Demand API include:

	Description
Logged-in deal	Available to eligible authenticated travellers. Previously referred to as Secret deals.
Limited-time promotions	A promotional discount with time-sensitive eligibility.
Black Friday campaigns	A promotional discount associated with the Black Friday campaign.
Early year deal	A promotional discount associated with an early-year campaign.
Flash deal	A promotional discount associated with a flash campaign.
Getaway deal	A promotional discount associated with a getaway campaign.
Late escape deal	A promotional discount associated with a late-escape campaign.

Target rates are rates offered to travellers who meet specific criteria, such as their booking platform or location.

You can use target rates to:

• Offer mobile-specific prices;
• Target travellers in specific countries or regions;
• Support market-specific pricing strategies.

Target rate types include:

	Mobile rates - Rates available to eligible travellers booking through a mobile platform.	Geo/country rates - Rates available based on the traveller's country.

Closed user group (CUG) rates are rates available only to eligible members of a defined user group.

For example, CUG rates can be used to provide eligible authenticated travellers with Genius or other membership-based rates.

To retrieve CUG rates:

• The traveller must meet the requirements of the applicable user group;
• You must provide the appropriate booker.user_groups values in the request;
• Your partner account must have access to the applicable rates.

CUG rates can also be combined with other discounts when rate stacking is enabled for your account.

Third-party inventory (TPI) rates are sourced from external suppliers and can supplement Booking.com inventory with additional availability and pricing.

TPI rates are available through Demand API v3.1 and later.

Depending on your partner configuration, TPI rates can be:

• Commissionable (Sell rates) - Belong to the regular rates group.
• Non-commissionable (Net rates) - Belong to the CUG rates group.

The discounts and rates returned by the Demand API depend on the request context.

Provide accurate traveller and booking information throughout the booking flow so that the API can determine which rates are applicable.

Use the following endpoints when retrieving and booking accommodation products:

The booker object describes the traveller context used to determine rate eligibility.

Provide the applicable values for the following parameters:

Include your API credentials as described in Authentication.

Your partner configuration determines which rates and discount programmes your integration can access.

To retrieve target rates, provide the traveller context that determines eligibility.

For example, to retrieve applicable mobile and country rates:

1. Set booker.platform to the platform the traveller is using, for example: mobile.

2. Set the booker.country to the traveller's country code, for example us. (Use the common/locations/countries endpoint endpoint to retrieve supported country codes.)

3. Provide the correct checkin and checkout dates.

For example:

{

  "booker": {
    "platform": "mobile", 
    "country": "us",
  },
  "checkin": "2026-12-05",
  "checkout": "2026-12-14",
  "extras": ["products"],

}

To retrieve rates that require an authenticated traveller, include authenticated in booker.user_groups

If the traveller is also eligible for a membership tier, include the corresponding user group, for example genius or genius2.

For example:

"booker": {
  "platform": "desktop",
  "country": "us",
  "user_groups": [
      "authenticated",
      "genius2"]
  },

In this example:

• authenticated indicates that the traveller is authenticated;
• genius2 requests rates applicable to that user group, where available to your integration.

Do not use a membership tier to represent authentication. For example, specifying only genius2 does not replace authenticated when authentication is required for the rate.

A product can be eligible for more than one type of discount.

For example, the following request provides:

• A mobile booking context;
• A traveller located in Spain;
• An authenticated traveller eligible for the genius user group; and
• The requested stay dates.

{

  "booker": {
    "platform": "mobile",
    "country": "es",
    "user_groups": ["authenticated", "genius"]
  },
  "checkin": "2026-12-05",
  "checkout": "2026-12-14",
  "extras": ["products"],

}

In this example, a combination of deals and CUG rates is applied:

• Target discounts are applied to mobile users located in Spain, during the selected period.
• For the exclusive Genius closed group, the user must be authenticated to receive special rates.

When product information includes an applicable discount, the response can contain a products.deal object, which provides summary information about the discounts applied to a product.

The following example shows an accommodation product with a 28% total discount.

Its public_price is 100.00, and its resulting price.book is 72.00. The returned tags indicate that the product includes a mobile rate and a limited-time deal.

{
  ...
  "currency": "EUR",
  "products": [
    ...
    "id": "xxxxxxxx_x_xxxxxxxxx_x_x_x",
    "deal": {
      "discount_percentage": 28,
      "public_price": 100.00,
      "tags": [
        "mobile_rate",
        "limited_time_deal"
      ]
    },
    ...
    "price": {
      "book": 72.00,
    },

The deal.tags array identifies characteristics or categories associated with the discounts applied to the product.

• Do not use deal tags as identifiers for an underlying promotion or pricing configuration.
• Different discounts can share the same tag, and the tags do not expose the rules used to calculate the price.

The following deal tags can be returned per version:

In version 3.3, deal tags provide more granular classifications for promotional campaigns.

The seasonal_deal tag is replaced by these tags:

More than one discount can contribute to the final price.

• When discounts can be combined, they can be applied sequentially.
• When discounts cannot be combined, the applicable pricing rules determine which discount is applied.
• Do not calculate the total discount from the values in deal.tags.

Use deal.discount_percentage to understand the total discount represented in the response rather than calculating the total from deal.tags.