From HTNG Connectivity Wiki

Jump to: navigation, search



The offer criteria resource stores information that is supplied by a user and is used to supplement the contextual data used for offer generation. Once an offer criteria object is created, a reference to this resource should be passed in with subsequent requests for offers.

The offer the criteria object is protected and is only accessible by the creating user (how TBD).

      • needs to be updated to reflect JSON Message***



POST: Post creates a new instance of an offer criteria returning it's unique ID or URL.

PUT: Updates an existing instance of an offer criteria.

GET: Retrieves an instance of an offer criteria.

    1. - check with Scott M. - DELETE: Team should discuss what "delete" means in this context (does it mean remove, cancel, or invalidate?)

GET: {OfferCriteriaID}/Offers - retrieves a list of offers based on criteria


  • hotelCode
  • stay (see Date Range Utility object)
    • arrivalDate (ISO8601)
    • departureDate (ISO8601)
  • roomTypeID (optional)
  • roomCount (optional, defaults to 1)
  • guestCounts[] (default to 1 adult, optional)
    • ageCategory (AQC : AGE QUALIFYING CODE)
    • count (int)
  • rateCode (organizational discounts, optional)
  • promoCode (specials, optional)
  • groupCode (for block rates, optional)
  • guestProfile (hyperlink, optional)



  • Questions for the group
    • Should we consider adding Amenity to the offer search criteria? It is not commonplace looking around at sites, however a good use case for it exists when searching for Accessible rooms. An simpler alternative would be to have a single ADA indicator on the object.
    • Searching for offers is currently limited to searching for a single room type, regardless of the number of the rooms requested. This intricacy does not appear to be commonly addressed on most sites I've looked at.
Personal tools
administrative tools