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.
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
CanonicalTravelportSource
-> providerCode 1G / 1V / 1P
-> provider locator/reference
-> normalized itinerary/order stateDo 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.
Planning a similar integration?
We can review requirements, feed/API design and the production approach with you.