OTA_TourActivitySearchRQ

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_TourActivitySearchRQ message is used to perform general search queries for tours and activities. Unlike OTA_TourActivityAvailRQ which focuses on availability for specific dates and participants, this message is designed for broader discovery searches, allowing users to browse and explore tour and activity options based on various criteria without necessarily committing to specific dates or participant counts.

Structure - Root Element

<OTA_TourActivitySearchRQ xmlns="http://www.opentravel.org/OTA/2003/05" Version="2011.2" PrimaryLangID="EN">

Attribute	Type	Required	Description
Version	String	Yes	Schema version being used
xmlns	String	Yes	”http://www.opentravel.org/OTA/2003/05”
TimeStamp	DateTime	No	Creation timestamp of the message
PrimaryLangID	String	No	Primary language code (ISO 639)
EchoToken	String	No	Reference for asynchronous transactions
MaxResponses	Integer	No	Maximum 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.

SearchCriteria

The core element containing all search parameters.

  <SearchCriteria>
    <DateTimePref Start="2026-07-17" End="2026-07-24"/>
    <LocationPref Context="Source">
      <Region RegionCode="HotelCode">AMTSES08UI</Region>
    </LocationPref>
    <LocationPref Context="Service">
      <Region RegionCode="Product">LESACE81AS</Region>
    </LocationPref>
    <OtherPref>
      <SpokenLanguage Code="EN"/>
    </OtherPref>
  </SearchCriteria>

DateTimePref

Specifies the date range for the excursion search (max 28 days). Duration can optionally be included.

<DateTimePref Start="2026-03-01" End="2026-03-15" Duration="P6h"/>

LocationPref

• 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.

<LocationPref Context="Source">
	<Region RegionCode="HotelCode">AMTSES08UI</Region>
</LocationPref>

OtherPref

Defines in this case spoken language preferences.

<OtherPref>
	<SpokenLanguage Code="EN"/>
</OtherPref>

CategoryTypePref (optional)

Optional section to filter by excursion categories.

<CategoryTypePref>
    <Category>Ticket</Category>
    <Type>Adventure</Type>
</CategoryTypePref>

Complete Examples

Search by Region

<OTA_TourActivitySearchRQ xmlns="http://www.opentravel.org/OTA/2003/05" Version="2011.2" PrimaryLangID="EN">
  <POS>
    <Source>
      <RequestorID ID="TST1" ID_Context="AxisData" Type="22"/>
    </Source>
    <Source>
      <RequestorID Type="88" ID="TST1" MessagePassword="TST1password?"/>
    </Source>
  </POS>
  <SearchCriteria>
    <DateTimePref Start="2026-07-17" End="2026-07-24"/>
    <LocationPref Context="Source">
      <Region RegionCode="HotelCode">AMTSES08UI</Region>
    </LocationPref>
    <LocationPref Context="Service">
      <Region RegionCode="Country">Spain</Region>
      <Region RegionCode="Region">Lanzarote</Region>
    </LocationPref>
    <OtherPref>
      <SpokenLanguage Code="EN"/>
    </OtherPref>
  </SearchCriteria>
</OTA_TourActivitySearchRQ>

Best Practices

1. Always include EchoToken - Essential for matching requests with responses.
2. Validate regions - Confirm region names before sending requests.
3. Be Specific: Include as many relevant search criteria as possible to get accurate results.
4. Date Ranges: Use reasonable date ranges to avoid overwhelming results.
5. Participant Details: Always specify participant counts and age categories for accurate pricing.
6. MaxResponses: Set appropriate limits to manage result sets.
7. Language: Specify PrimaryLangID to receive results in the desired language.
8. Time Zones: Be aware that timestamps should include timezone information.
9. 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!