Pricing
Provides pricing information to various endpoints
To use this capability, add octo/pricing to your Octo-Capabilities header.
This capability supports dynamic pricing where the price of the product can be changed day by day and even at different start times. Make sure your system is able to support this level of pricing before you integrate with it.
This capability extends product routes documented in Products:
GET /productsGET /products/{productId}
This pricing extension is returned on both GET /products and GET /products/:productId.
On the response, pricing adds the following fields on the Product object:
defaultCurrency is the fallback currency. availableCurrencies are all valid currencies for this product. includeTax indicates whether product prices already include tax. hidePricingFrom indicates whether from-prices should be hidden in UI contexts.
pricingPer indicates whether pricing is per unit (most common) or per booking.
If pricingPer = "UNIT", each option unit/item includes pricingFrom.
If pricingPer = "BOOKING", each option includes pricingFrom instead.
If currency is omitted, pricing arrays include one object per value in availableCurrencies. If currency is set (or set to default), pricing arrays contain a single object.
Throughout this capability, fields ending with From are indicative prices and not final prices. Make sure this is communicated clearly to customers.
This capability extends availability calendar routes documented in Availability:
POST /availability/calendarGET /availability/calendar
This pricing extension is available on both GET /availability/calendar and POST /availability/calendar.
The documentation above only shows the additions this capability adds to the availability calendar endpoint. See the documentation here to see the full request parameters and response object.
units supports nested fields:
Using the availability calendar endpoint for pricing is designed to make it easy to generate a pricing calendar for example on Google Travel:
Each availability object is given:
unitPricingFrom: an array of unit/item prices, each withunitIdandunitTypepricingFrom: a total pricing object for the availability (forpricingPer = UNIT, this is only meaningful onceunitsare passed)
If you pass units, pricingFrom returns the total pricing for that selection. For pricingPer = BOOKING, pricingFrom is still returned without unit selection because booking pricing is not ticket-count driven.
Having the pricingFrom value calculated for you makes it much easier to display a single price on each date on the calendar (assuming the guest has chosen how many units they want before you display the calendar).
For pricingPer = BOOKING, unitPricingFrom may still be present for item-style units (type OTHER) and can be an empty array.
This capability extends availability check routes documented in Availability:
POST /availabilityGET /availability
This pricing extension is available on both GET /availability and POST /availability.
unitPricing rows include unitId and unitType, plus the shared pricing object fields described earlier.
units uses the same schema shown in the availability calendar section (id, quantity, optional weightValue and weightUnit). Availability extras use objects with id and quantity.
This endpoint is the availability check endpoint which has been extended to add pricing. We only document the added parameters here, to see the full documentation for the original availability check you can find it here.
Notice how the response fields are unitPricing and pricing (without the From suffix). That is because this is the final price, and this is what the booking will be once confirmed.
Batch variants (POST /availability/batch and POST /availability/calendar/batch) return the same pricing extensions because they proxy these same endpoints.
This capability extends booking write routes documented in Bookings:
POST /bookingsPATCH /bookings/{uuid}POST /bookings/{uuid}/confirm
This capability extends booking responses to add a final pricing object. The final price includes tax and is the amount to show/pay.
This pricing payload is returned anywhere a booking object is serialized (booking write/read/cancel/extend routes in Bookings).
If request pricing is provided, it must match the server-calculated booking totals.
Base booking schema: Bookings.
If a partner has enforced price-matching and no matching pricing object is sent, the request fails with PRICING_MATCH_REQUIRED.
Write endpoints that build/update booking/order/gift records also accept currency. You can pass default to use the preferred currency automatically.
Booking payloads can include pricing at these paths:
pricingavailability.pricingavailability.unitPricing[]option.pricing(forpricingPer = BOOKING)option.units[].pricingandoption.units[].pricingFrom(depending on unit type/selection state)unitItems[].pricingunitItems[].unit.pricing
Additional pricing serialization using the same pricing object schema:
Order responses include
pricingon order write/read/cancel/extend routes (see Multi-Booking Cart).Gift responses include
pricingon gift write/read/cancel/extend routes (see Gift Vouchers).Destination objects serialized by
octo/contentincludedefaultCurrencyandavailableCurrencies.
Schema Additions (JSON)
These are additive fragments showing only fields introduced by this capability.
Availability
AvailabilityAvailabilityBatchRow
AvailabilityBatchRowAvailabilityCalendar
AvailabilityCalendarAvailabilityCalendarBatchRow
AvailabilityCalendarBatchRowBooking
BookingBookingUnitItem
BookingUnitItemError
ErrorExtraPricing
ExtraPricingGift
GiftMoney
MoneyOption
OptionOrder
OrderPackageAvailability
PackageAvailabilityPricing
PricingProduct
ProductUnit
UnitUnitPricing
UnitPricingLast updated