Protocol v1.0 · Partner supply reference
Supply Offer Profiles
Use a registered profile when your Offer carries structured domain facts that consumers can reliably inspect. Generic Offers remain valid and omit offer_info.details.
- Protocol selector
1.0- Offer model lineage
3.0- Details envelope
- Optional
- Registered profiles
- 2
offer_info.detailsdetails.profiledetails.dataoffer_info.category.id remains the AON Taxonomy v1 classification. The profile selector chooses a closed, machine-readable data shape and does not replace the category.
Stable registry
Registered profiles
Each reference combines canonical field constraints, profile-specific semantics, and a valid Partner Offer example.
flightA priced air itinerary with traveller composition, ordered legs, and scheduled segments.
- Category family
- travel_tourism.air_travel.airline_tickets_fares_flights
- Required data
- trip_type · travelers · legs
hotel_rateA source-observed starting nightly price for an identified hotel property.
- Category family
- travel_tourism.accommodations.hotels_motels_resorts.hotels
- Required data
- rate · property
Choose the representation your source can support
Supply every required fact for the selected profile and omit unknown optional branches. Profile objects are closed, so undeclared fields are invalid.
Omit offer_info.details when the source cannot support a registered shape. Do not infer dates, room types, traveler counts, or itinerary facts.
Contract boundary
Partner input is richer than the generic consumer projection
A Partner may supply registered details, source price context, and profile semantics in the v1.0 Partner Offer.
Consumers follow their own response contract. A generic Query projection can omit details, tax_status, and quote; Partner input fields are not universally exposed.
Canonical contract
Generated facts, authored guidance
Field types, requiredness, enums, formats, and limits come from the v1.0 JSON Schema. This page is built from protocol-v1.0.0-r15.