Leg
Itinerary içindeki origin-destination yönüdür; outbound/return gibi düşünülebilir. Bir leg birden fazla segment içerebilir.
Neden önemli?
Flight domain'inde itinerary, leg, segment, carrier ve seller identity birbirinden farklıdır. Bu entity'leri yanlış flatten etmek schedule, fare, agent ve booking rule'larını karıştırır. Search UI sade olabilir; fakat source model repricing ve handoff için yeterli ayrıntıyı korumalıdır.
Pratikte nasıl görünür?
Aynı itinerary farklı agent'larda farklı fare brand, baggage ve booking condition ile satılabilir. Segment schedule ile seller/offer identity aynı entity değildir.
Uygulamada sorulması gerekenler
- Itinerary hangi leg/segment'lerden oluşuyor?
- Marketing ve operating carrier ayrılıyor mu?
- Agent/provider identity korunuyor mu?
- Offer repricing için source reference mevcut mu?
Yaygın hatalar
- Flight number + price ile offer modellemek
- Marketing ve operating carrier'ı karıştırmak
- Agent identity'yi itinerary identity'ye gömmek
Travel stack içinde nerede kullanılır?
Leg, çoğunlukla flight katmanlarıyla ilişkilidir. İlgili sistemlerde source-of-truth, identity, freshness ve transaction ownership sınırlarını açık tanımlamak gerekir.
İlgili terimler
İlgili teknik içerikler
Agentic Travel Authorization, Mandate ve Human-in-the-Loop
AI agent'ın travel purchase ve servicing side-effect'leri için user intent, mandate, delegated authority ve human-in-the-loop checkpoint'lerini tasarlayın.
İncele →Agoda: OTA ve Multi-Vertical Travel Marketplace Profili
Agoda'yı accommodation, flight ve activity inventory'sini consumer booking journey'de birleştiren OTA/travel marketplace olarak inceleyin.
İncele →Skyscanner Flight API Entegrasyonu: Developer Rehberi
Skyscanner Flights Live Prices API entegrasyonunu x-api-key auth, create/poll lifecycle, request-response modelleri, itinerary/leg/segment mapping, agent/pricing option, rate limit, polling ve observability ile developer gözüyle uygulayın.
İncele →