---
title: "Travelport Historical Context: Galileo, Apollo and Worldspan"
description: "Understand how Galileo (1G), Apollo (1V) and Worldspan (1P) remain relevant as provider identities and historical GDS context inside Travelport integrations."
slug: "travelport-galileo-apollo-worldspan-history"
translationKey: "guide-travelport-galileo-apollo-worldspan-history"
locale: "en"
type: "guide"
category: "flight"
tags: ["travelport","galileo","apollo","worldspan","gds","history"]
publishedAt: "2026-09-27"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
sources:
  - title: "Travelport Universal API — Content Providers"
    url: "https://support.travelport.com/webhelp/uapi/Content/Getting_Started/Before_You_Begin/Content_Providers_and_Suppliers.htm"
  - title: "Travelport Universal API — Reference Data"
    url: "https://support.travelport.com/webhelp/uapi/Content/Getting_Started/Design_Considerations/Reference_Data.htm"
---
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.