Leg
An origin-to-destination direction within an itinerary, such as outbound or return. A leg may contain multiple segments.
Why it matters
In the flight domain, itinerary, leg, segment, carrier and seller identity are distinct. Flattening them too aggressively mixes schedule, fare, agent and booking rules. The search UI can be simple, but the source model needs enough detail for repricing and handoff.
What does it look like in practice?
The same itinerary can be sold by multiple agents with different fare brands, baggage and booking conditions. Segment schedule and seller/offer identity are different concepts.
Implementation questions
- Which legs and segments form the itinerary?
- Are marketing and operating carriers separated?
- Is agent/provider identity retained?
- Is the source reference available for repricing?
Common mistakes
- Modeling an offer as flight number plus price
- Mixing marketing and operating carriers
- Embedding agent identity into itinerary identity
Where does it appear in the travel stack?
Leg commonly appears across flight layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.
Related terms
Related technical guides
Agentic Travel Authorization, Mandates and Human-in-the-Loop
Design user intent, mandates, delegated authority and human-in-the-loop checkpoints for AI-driven travel purchase and servicing side effects.
Explore →Skyscanner Flight API Integration: Developer Guide
Implement Skyscanner Flights Live Prices with x-api-key authentication, create/poll lifecycle, request-response models, itinerary/leg/segment mapping, agents, pricing options, rate limits and observability.
Explore →Amadeus Self-Service: Retired API Platform and Migration
Legacy Amadeus Self-Service API scope, portal retirement and migration to separately contracted Enterprise access.
Explore →