Skip to main content
Already know OTA messages? Jump straight into testing.

OTA_TourActivity API call

Skip & Hit the Playground.

​
Search VS Avail

To get activities from the system we have 2 message-types:

​
OTA_TourActivitySearchRQ

This is a search request message used to:
  • Find available tour and activity products based on search criteria.
  • Query what tours/activities are offered in a destination.
  • Filter by location, dates, activity types, price ranges, etc.
  • Get a broad list of matching products.
  • Get NBC data for the matching products.
  • Get “best scenario” cheapest price for the matching products.
Think of it as the initial discovery phase - “What tours are available in Rome next week?”

​
OTA_TourActivityAvailRQ

This is an availability request message used to:
  • Check specific availability for a particular tour or activity.
  • Get detailed pricing, time slots, and capacity for a known product.
  • Verify real-time availability before booking.
  • Retrieve detailed schedules and options for a specific offering.
Think of it as the detailed inquiry phase - “Is the Colosseum tour available at 2 PM on Tuesday for 4 people, and how much does it cost?” Key Difference Search = “Show me what exists” (broader, exploratory). Availability = “Tell me if this specific thing is available” (narrower, transactional). In a typical booking flow, you’d use SearchRQ first to find options, then AvailRQ to check specific details before making a booking with OTA_TourActivityBookRQ.

​
Purpose

The OTA_TourActivityAvailRQ message is used to request availability information for tours and activities. This request allows travel systems to query suppliers for available tour and activity products based on various search criteria including dates, locations, categories, and participant information.

​
Structure - Root Element

<OTA_TourActivitySearchRQ xmlns="http://www.opentravel.org/OTA/2003/05" Version="2011.2" PrimaryLangID="EN">
AttributeTypeRequiredDescription
VersionStringYesSchema version being used
xmlnsStringYes”http://www.opentravel.org/OTA/2003/05”
TimeStampDateTimeNoCreation timestamp of the message
PrimaryLangIDStringNoPrimary language code (ISO 639)
EchoTokenStringNoReference for asynchronous transactions
MaxResponsesIntegerNoMaximum number of results to return

​
Structure - Core Elements

​
POS (Point of Sale)

Identifies the party or connection making the request. 
  <POS>
    <Source>
      <RequestorID ID="TST1" ID_Context="AxisData" Type="22"/>
    </Source>
    <Source>
      <RequestorID Type="88" ID="TST1" MessagePassword="TST1password?"/>
    </Source>
  </POS>
Identifies the requesting party and contains credentials. Check Access to our Systems.

​
Instance

SwitchBehavior
MF002Returns one cheapest price per service (price-from, per person).
MF001Returns all schedules and all products/subservices for the selected service (prices per group).
Recommended workflow: Initial search with MF002 per area for cheapest prices, then detailed search with MF001 per product for selected service.

​
TourActivity

Core element containing search criteria for tours and activities. 
  <TourActivity>
    <BasicInfo/>
    <Location Context="Source">
      <Region RegionCode="HotelCode">AMTSES08UI</Region>
    </Location>
    <Location Context="Service">
      <Region RegionCode="Product">LESACE81AS</Region>
    </Location>
    <Schedule StartPeriod="2026-07-17" EndPeriod="2026-07-24"/>
    <ParticipantCount Quantity="1">
      <QualifierInfo>10</QualifierInfo>
    </ParticipantCount>
    <MultimodalOffer>
      <RequestedOffer>
        <GuidelinePricing>
          <Method>PerPerson</Method>
          <MaximumPrice Amount="999" CurrencyCode="EUR" CurrencyDecimal="2"/>
        </GuidelinePricing>
      </RequestedOffer>
    </MultimodalOffer>
  </TourActivity>

​
Location

  • Two contexts: Context="Source" (guest origin/pick-up base) and Context="Service" (where the activity runs).
  • Use one location type per context: Areas (Country → Region → Resort), HotelCode, GIATA, Product, or geocode via Position.
  • When using areas, always include Country.
  • Source locations allowed: Area (Country, Region, Resort), GIATA code, Hotel Code or Geo Location.
  • Destination locations allowed: Area (Country, Region, Resort), TourActivity Code.
<Location Context="Source">
	<Region RegionCode="HotelCode">AMTSES08UI</Region>
</Location>

​
Schedule

Defines temporal search criteria:
  • StartPeriod: Start date for availability search.
  • EndPeriod: End date for availability search.
<Schedule StartPeriod="2026-07-17" EndPeriod="2026-07-24"/>
Duration can optionally be included.

​
ParticipantCount

Details about participants: 
<ParticipantCount Quantity="1" Age="26">
	<QualifierInfo>10</QualifierInfo>
</ParticipantCount>
Age QualifierInfo Codes:
  • 8: Child
  • 10: Adult
  • 7: Infant

​
MultimodalOffer

Can be used to specify a maximum price and it’s type (PerPerson, PerUnit). 
<MultimodalOffer>
    <RequestedOffer>
    <GuidelinePricing>
        <Method>PerPerson</Method>
        <MaximumPrice Amount="999" CurrencyCode="EUR" CurrencyDecimal="2"/>
    </GuidelinePricing>
    </RequestedOffer>
</MultimodalOffer>

​
Complete Examples

<OTA_TourActivityAvailRQ xmlns="http://www.opentravel.org/OTA/2003/05" Version="2011.2">
  <POS>
    <Source>
      <RequestorID ID="TST1" ID_Context="AxisData" Type="22" Instance="MF001"/>
    </Source>
    <Source>
      <RequestorID Type="88" ID="TST1" MessagePassword="TST1password?"/>
    </Source>
  </POS>
  <TourActivity>
    <BasicInfo/>
    <Location Context="Source">
      <Region RegionCode="HotelCode">AMTSES08UI</Region>
    </Location>
    <Location Context="Service">
      <Region RegionCode="Product">LESACE81AS</Region>
    </Location>
    <Schedule StartPeriod="2026-07-17" EndPeriod="2026-07-24"/>
    <ParticipantCount Quantity="1">
      <QualifierInfo>10</QualifierInfo>
    </ParticipantCount>
    <MultimodalOffer>
      <RequestedOffer>
        <GuidelinePricing>
          <Method>PerPerson</Method>
          <MaximumPrice Amount="999" CurrencyCode="EUR" CurrencyDecimal="2"/>
        </GuidelinePricing>
      </RequestedOffer>
    </MultimodalOffer>
  </TourActivity>
</OTA_TourActivityAvailRQ>

​
Common Use Cases

  • Product Availability Request: Searches a specific activity, ideally with instance MF001 to get all the possible results of the product.
  • Region Availability Request: Searches multiple activities in one region, ideally with instance MF002 to get only the cheapest combination of each product.

​
Best Practices

  1. Be Specific: Include as many relevant search criteria as possible to get accurate results.
  2. Date Ranges: Use reasonable date ranges to avoid overwhelming results.
  3. Participant Details: Always specify participant counts and age categories for accurate pricing.
  4. MaxResponses: Set appropriate limits to manage result sets.
  5. Language: Specify PrimaryLangID to receive results in the desired language.
  6. Time Zones: Be aware that timestamps should include timezone information.
  7. Error Handling: Implement proper error handling for the response messages.

​
Playground

OTA_TourActivity API call

Hit the Playground.
Use the desired request at the playground and receive responses from our test environment API!