Travelport Historical Context: Galileo, Apollo and Worldspan

Understand how Galileo (1G), Apollo (1V) and Worldspan (1P) remain relevant as provider identities and historical GDS context inside Travelport integrations.

Editorial information
Advertisement

Galileo, Apollo and Worldspan should not be modeled as three unrelated current API vendors. In Travelport integrations they remain important provider identities and historical GDS lineages.

Provider codes

Travelport Universal API documentation identifies:

  • Galileo — 1G
  • Worldspan — 1P
  • Apollo — 1V

Provider-specific codes and behavior can still differ.

Why legacy identity matters

Historical/provider identity can affect:

  • PNR/provider locator,
  • fare/pricing behavior,
  • reference data,
  • command formats,
  • supported functions.

A canonical Travelport layer should normalize these differences without erasing their source.

Current naming

Travelport documentation notes that Travelport+ is the newer name/reference for Galileo in some contexts, while older help systems can still call the provider Galileo (1G).

Migration rule

text
CanonicalTravelportSource
  -> providerCode 1G / 1V / 1P
  -> provider locator/reference
  -> normalized itinerary/order state

Do not migrate old records by replacing provider codes with one generic “Travelport” value.

Why this belongs in one guide

The useful engineering question is legacy/source compatibility inside Travelport, not which historical GDS brand should be added as a separate ecosystem entity.

Technical advisory

Planning a similar integration?

We can review requirements, feed/API design and the production approach with you.

Discuss your project →

Sources

Related content