HTNG, HEDNA, and OpenTravel have collaborated to publish a new OpenTravel 1.0 release featuring significant enhancements from the HTNG Optimizing Lodging Content Workgroup. New data fields include details on accessibility, sustainability, health and safety measures, and more.
These updated documents address:
What’s next: This joint workgroup will make complementary updates to the OpenTravel 2.0 Object Model, including JSON/REST APIs, to support evolving hospitality needs.
Why it matters: HTNG continues to lead hospitality message development by managing workgroups and defining requirements. OpenTravel complements this effort by overseeing the industry-wide publication and management of travel retail standards. Collaborating with HEDNA further strengthens this ecosystem, ensuring seamless distribution and payment integration in the hospitality sector. These partnerships remain strong, with additional HTNG workgroups actively shaping future releases to meet the industry’s ever-changing needs
New fields were added to the content messages to support:
New fields added to availability and booking messages:
Code lists were updated about 17 times over the course of this two year effort. Part of the effort was the team went back to their companies to look at fields that codes that were missing, and they found quite a lot. This extended the life of the workgroup, but the needs were there so well worth it. The codes added were numerous, covering the following areas.
You can access the latest release by filling out a request form.
Open Travel supports to groups of messages known as OTA 1.0 and 2.0. The 1.0 messages are the original XML versions created since 2000. The 2.0 messages are based on model driven development which you can read about on the website. They use the Open Travel open source tool, known as DEx, to transform the model into both XML (.xsd) and JSON (OAS 3.0) formats.
The 2024A release is a critical update to the 1.0 (XML) messages to support current business needs still using XML. Adopting the new codes we expect will happen rapidly. Adopting changed or new messages takes longer because there is a lot more work on the part of implementers to upgrade to a new version of the message. The API consumers can ignore new codes but they can’t ignore message changes, hence longer timelines for them as well.
As stated above, the workgroup will continue to add the same features to the 2.0 version. In time, we expect fewer updates to 1.0 as users focus on moving to JSON. Note while doing 1.0 and 2.0 sounds like double work, the 1.0 effort significantly speeds up the 2.0 work. The business needs and use cases are defined once. The 2.0 work focuses on how to represent the data elements in object format to support JSON/REST architectures.