How to Name Our Travel API? – The Challenges of Branding!

In an industry where agility and integration are key, naming can be pivotal in shaping a product’s perception. In this article, we reflect the challenges of renaming our Travel API. You can vote on a new name via the LinkedIn page of the author.

Our travel aggregation platform has come a long way since its inception as an XML-based (Extensible Markup Language) interface, built to connect global travel giants like Amadeus, Sabre, and other GDSs. Now, with a reach extending to 50 different travel content sources and a modernized REST API infrastructure, we find ourselves questioning if “Travel XML API” still encapsulates the strength and relevance of our platform in today’s market. With developers viewing XML as outdated and client needs evolving, we’re considering a rebrand to better reflect our technology’s performance, versatility, and modern approach to travel distribution.

Is XML antiquated?

In our recent meeting with the marketing team, we spent quite a little bit of time discussing how we should name our travel aggregation platform that allows billions of travelers, travel arranger, travel risk manager and many more to access up to fifty sources of travel content providers (airlines, hotels, rental car companies, Global Distribution Systems, other travel aggregators, low-cost carriers, etc.) through one single interface. Up until today we have called it Travel XML API and nicely enough, we are ranked at the #1 top spot on Google. At the same time – and rightfully so – our developers are telling us that this name is ‘antiquated’ and developers run away when they hear XML.

How did we come up with Travel XML API?

When we started developing our first XML aggregation platform connecting Amadeus, Galileo, Worldspan and Sabre (sometimes via EDIFACT) and made it available to our clients through a single XML interface, this was back in the year 2000 and XML actually was a milestone compared to EDIFACT.

What is the problem with XML in travel technology?

XML itself is already considered overloaded as it generates large files. XML being a plain text format is not memory efficient to start with. With all the additional tags around the actual data, files can become extremely large. In many cases, the tags can take up more room than the actual data! Combine that with peer-to-peer connections, stopovers, times of travel during a certain period, the number of airlines competing in a certain market, the different fare types (not to even mention continuous pricing), classes, bags, seats, refundability, changeability and more, the files grow exponentially and become a multidimensional problem. Today, people want REST instead of SOAP as a data exchange technology and JSON instead of XML as a data format – leading to small messages and high performance. This is why we actually created a new API based on REST.

Why did we think we should keep the term XML?

The answer is that the new airline distribution standard NDC is based on XML (actually our XML schema from back in 2000). I always joked about IATA calling NDC their New Distribution Capabilities to shop and book air inventory. I’m a pure engineer with no marketing background and acquired my commercial skills in a marketing department in the cellphone area. One thing I learned there is never to call anything “new”. What do you do the following year? Is it still new? So NDC has been around over a decade now. Why do we still call NDC “new”? XML may be newer than 50–60-year-old EDIFACT, but compared to other industries in internet age, XML is old. Stable but old.

So, how should we name our product in future? How are you being found?

With search term Travel XML API we can be found on position #1 on Google. It even has a fair search volume. But do developers and potential clients actually turn away when they read XML? Should we call our platform GDS integration? Or GDS aggregator? Both search terms our clients confirmed they used in their challenging journey to find us.

Should we focus on Global Distribution Systems (GDS)?

Being able to flawlessly integrate all the different Global Distribution Systems (Amadeus, Sabre and the Travelport Systems Galileo/Apollo, Worldspan) specifically with the traditional ATPCo/EDIFACT workflow is probably our strongest suit, but doesn’t the name GDS aggregator diminish our capabilities? Today we aggregate up to 50 source systems and only three of them are GDS! Many airlines (and there are up to 500 airlines in the world) distribute directly via NDC.

Can you help us?

GDS aggregator minimizes our product offering. We are told that with XML we are regarded as an antiquated company. Our product name XX1 has a dubious secondary meaning: I hear that some may consider XX.. something different than ‘with XML (X) connect many (X) sources through one (1) interface’ … hence we are back to the drawing board scratching our heads trying to figure out what would be the best keyword for our product offering.

Please vote on LinkedIn! 

Would you like to give us feedback on the name search? Then please use the voting tool on the author’s LinkedIn page.

There we put 4 name suggestions to the vote:

  1. GDS Integrator or GDS Aggregator
  2. Travel API or Travel Technology API 
  3. Travel Distribution API or Travel Distribution platform
  4. Travel XML API

Do you have a better suggestion or further comments? Then please fill in the comments section.

PASS SolutionWorld Travel

The PASS SolutionWorld Travel is a technical vehicle to connect the relevant players in the market and to make today's world available as efficiently and precisely as possible for the industry. The primary topic is to make the content of the various providers in the market bookable through a uniform process – either via the multi-source microservices API (iXX1) or directly in a uniform booking interface (such as the Travel Agent Desktop) and to digitally map the upstream and downstream processes and integrate the relevant players.
Tip!

Header picture: Shutterstock

Leave a Reply