Handling Prices


WuBook supports multiple Pricing Plans for each property, also known as rates. If you connect WuBook to provide a channel manager service, you need to provide the possibility to manage them, because the connectivity to your OTAs depends on that: booking.com and expedia, for example, require different prices for different rates and you must be able to manage these features.

There are two kind of plans: Intensive and Daily. You can safely manage only Daily Pricing Plans to develop a complete solution. This is also recommended (unless particular cases, see below).

Intensive plans contain prices depending on ranges of dates and on the day of week. For example:

From 10/10 To 12/12

  Room1: Monday= 100, Tuersday= 110, ...., Sunday= 150
  Room2: Monday= 50, ....                  Sunday= 100

Intensive plans are used when prices are very simple and do not vary so much during the year. In other words, for properties applying basic rules of marketing. For example, to define different prices depending only on High/Medium/Low season. Intensive plans are also used to manage Virtual Plans (see below).

Each Intensive Pricing Plan has default prices for each room: this way, for not defined range of dates, prices continue to be well defined.

Daily plans are more flexible and probably easier to be updated. Inside a daily pricing plan, each room has its own price for each day. Standard way.

WuBook supports also Virtual Plans (which are Intensive Plans), which inherit, with a percentage or static variation, prices from another plan. Even if a virtual pricing plan inherits the prices from another plan, it’s possible to define particular prices for particular range of dates: this way, you can have a default inheritance and, at the same time, the possibility to change things for specific ranges of dates.


Unless you need to manage existing Intensive Plans or Virtual Plans (i.e., unless particular needs), our advice is to just and always use Daily Pricing Plans, which are more flexible and, at the same time, easier.

The WuBook Parity

Each property has a standard pricing plan: the WuBook Parity. This pricing plan contains the default prices for the Online Reception (the wubook booking engine). If the Online Reception of WuBook is not used, the WuBook Parity is like another pricing plan, without particular features.


the WuBook Parity Pricing Plan has always ID= 0 for each property and can not be removed

By default, the WuBook Parity pricing plan is a Daily Pricing Plan. However, you can elect a Pricing Plan to represent the WuBook Parity (also Intensive, so generally used for simple marketing needs). This can be done on the WuBook Control Panel (property extranet).

If you do that (probably it is a useless complexification), you must update the elected plan to manage it.

Pricing plans management

To add a new Pricing Plan, the following function is used:

add_pricing_plan(token, lcode, name[, daily= 1])

This function returns the ID of the new plan. If daily is 1, you are building a Daily Pricing Plan. Use daily= 0 to have an Intensive Plan.

To add a new Virtual Pricing Plan, you use:

add_vplan(token, lcode, name, pid, dtype, value)

Where pid is the Plan Id of the Parent Pricing Plan, while dtype is an integer:

  • -2: This plan is a discount. Value is a fixed amount
  • -1: This plan is a discount. Value is a percentage
  • 1: This plan increases prices. Value is a percentage
  • 2: This plan increases prices. Value is a fixed amount

Given the dtype integer, value is the quantity of the variation (a float or an integer), for example:

  • variation= 10, variation_type= 1: you have an increase of 10%
  • variation= 30, variation_type= -2: you have a decrease of 30 EUR (currency being obviously dynamic)


Functions adding a new plan always return the assigned ID

To remove a pricing plan, one uses:

del_plan(token, lcode, pid)

where pid is the ID of the plan which must be removed.

To update the name of a pricing plan:

update_plan_name(token, lcode, pid, name)

Finally, to fetch the existing pricing plans of a property, there is the following function:

get_pricing_plans(token, lcode)

The return value of this call is an array, each element being a Pricing Plan. Each item is a KV structure, containing the following fields:

Field Description
id Eh, the ID of the plan
name The name of the plan
daily 1 if the plan is daily, 0 if it’s intensive
vpid If plan is virtual, this is the PID (plan id) of its parent
variation If plan is virtual, this is the price variation amount
variation_type If plan is virtual, this is the price variation type

About variation and variation_type, check the documentation of add_vplan()

update_plan_rack(token, lcode, pid, rack)

Pricing plans have default values (when default values of a pricing plan are not specified, the default prices become the default room prices, see the rooms section). The update_plan_rack() function is used to modify them. The rack argument is a KV structure:

  '1': [1,2,3,4,5,6,7],
  '2': [1,2,3,4,5,6,7],

For each room, you specify the default price depending on the day of the week (so, arrays have always lenght= 7).

mod_vplans(token, lcode, plans)

The function mod_vplans allows to manage Virtual Plans, modifying the variation and the variation_type. The plans argument is an array of KV structures, each one containing information about the ID of the plan and the desired variation_type/variation, like that:

plans= [{'pid': 1, 'variation': 10, 'variation_type': 1}, {'pid': 2, 'variation': 10, 'variation_type': -2}]

Handling Daily Plans

There are just two functions to completely manage Daily Pricing Plans. One is used to write, the other to read:

update_plan_prices(token, lcode, pid, dfrom, prices)
fetch_plan_prices(token, lcode, pid, dfrom, dto[, rooms= []])

To update the values of a Pricing Plan, you use update_plan_prices(). The pid parameter is the ID of the Pricing Plan you want to modify. The dfrom parameter is the Starting Date (european format: 21/12/2021). The prices parameter is a KV structure. Keys are Room IDs. Values are array of prices. The following example will explain it better:

prices= {
  "1": [100, 101, 102],
  "2": [200, 201, 202]

The previuos KV structure is used to setup the following prices (assming dfrom= 21/12/2021):

Room Id: 1
  21/12: 100
  22/12: 101
  23/12: 102

Room Id: 2
  21/12: 200
  22/12: 201
  23/12: 202

The underlying xml (for the Room with id= 1) is:


Finally, click on the following link for a full representation of the update call described on our example.

+ show/hide code

The function fetch_plan_prices() is used to read current values of one pricing plan. The dfrom and dto arguments are used to select a range of dates. You use the rooms parameter (an array of integers, each one representing a room ID) if you are just interested on a particular set of rooms (otherwise, prices of all rooms are returned).

The return value is a KV structure, very similar to the one used to modify prices (see update_plan_prices())

Handling Intensive Plans

As already stated before, if possible do not develop Intensive Plans functions. Dealing with Daily Pricing Plans is easier and enough on the great part of cases.

Anyway, to manage Intensive Pricing Plans you have the following functions:

convert_to_daily_plan(token, lcode, pid)
update_plan_periods(token, lcode, pid, periods)
delete_periods(token, lcode, pid, delperiods)

The function convert_to_daily_plan() is used to transform an Intensive Pricing Plan to a Daily Pricing Plan. Very useful if you have existing Intensive Pricing Plan and you correctly want to manage only Daily Plans.

The function update_plan_periods() is used to modify prices. As described on the introduction of this chapter, Intensive Pricing Plans define prices depending on the range of dates. Moreover, inside each range of dates, you can differentiate prices depending on the day of the week.


We will introduce soon a limit on the number of periods supported by each intensive pricing plan. So, please, use intensive plans only when you have few ranges of dates to manage!

The periods argument is used to specify prices and range of dates. It is an array, each element containing a range of dates and relative prices. Each element is a KV structure containing three fields: dfrom, dto and values. The values key contains the prices and it’s equal to the structure used for the function update_plan_rack(). That’s an example:

periods= [
    'dfrom': 21/10/2021',
    'dto': 12/12/2021',
    'values': {
      '1': [1,2,3,4,5,6,7],
      '2': [1,2,3,4,5,6,7],
    'dfrom': 21/10/2080',
    'dto': 12/12/2080',
    'values': {
      '1': [1,2,3,4,5,6,7],
      '2': [1,2,3,4,5,6,7],

Click on the following link to have an example of the underlying xml.

+ show/hide code

Now that you know how to define prices for particular ranges of dates, you can have the need to delete them (restoring that way the default prices of the pricing plan -rack-). To do that, one uses delete_periods(). This time, the argument periods is a list of KV structs which contains just ranges of dates, like that:

periods= [{'dfrom': '10/12/2020', 'dto': '20/12/2020'}, {'dfrom': '10/01/2040', 'dto': '20/01/2040'}]