Skip to main content

Deprecation notices and migration guide from Intrepid Legacy API/XML Feeds to Partner Platform REST APIs

Intrepid has deployed a new and improved Partner API Platform specifically for our partners who wish to integrate using our REST APIs. This guide outlines the deprecation timeline of our legacy API and shows you how to update your integration to adopt the new Partner Platform REST APIs. It describes the changes and improvements and provides appropriate migration paths.

Improvements​

The new Partner API offers several improvements over the Public API/XML feeds:

  • Cancellation Terms & Fees: All trip products now include the relevant cancellation terms and fees, making those available to you for display to your consultants and/or customers at relevant points in their booking journey.
  • Promotional Pricing: If you have any exclusive promotions set up with Intrepid, these discounted prices (and their relevant promotion details) will now be returned to you when querying departures for you to display to your consultants and/or customers at time of booking. Note that only those promotions that are currently live will be included. Future-dated promotions are not returned.
  • Expanded Itineraries: When requesting the itinerary of a particular Trip Code all valid versions are now returned, whether the current/default one or the previous or next one, each with its relevant (departure start date) validity dates.
  • Trip Images in Trips API: Images for all our trips are now retrievable through our trips API. Previously this was only available through our product XML feed.
  • Related Trips in Trips API: Packaged and related trips are now retrievable for combo trips through our trips API.
  • Related Departures in Departures API: Packaged and related departures are now retrievable for combo trips through our departures API.
  • Trip Notes in Trips API: Trip notes for all our trips are now retrievable through our trips API. Previously was only available through our trip notes XML feed.
  • Simplified Multi-room Trips: Variable Room Type Trips (VRTT) are now represented as a single trip resource, with a single corresponding departure resource. Each VRTT departure resource will then have multiple room options that represent each cabin/room type reservable for that trip, each with its own pricing and availability.
  • Conditional Pricing: Family and multiple passenger discounted prices are now available in our API responses

Changes​

There are several changes to be considered if you are consuming our APIs or XML feeds, including:

  • Changes to how you authenticate: Modern OAuth 2.0 authentication has replaced the traditional API key authentication methods.
  • Changes to how you request information: New RESTs API endpoints have been built to better support our growing suite of products (e.g. trips, accommodation, transfers, activities). Each product has their own data model and APIs. You will no longer need to use our XML feeds to retrieve trip product/departure details; instead you will use the various Product API requests.
  • Changes to how we return information: Utilising RESTful best practices, our API now returns standard HTTP status codes, consistent response structures and standardised error messages with validation rules.

Deprecation​

As of XX-XX-XXXX, The Public API and XML Feeds will become deprecated, and technical support will no longer be offered by Intrepid. Partners will be required to migrate their integration over to the Partner API Platform, and its various API endpoints, to request all Product and Departure data. The Public API and XML Feeds will remain available for use by our existing partners until XX-XX-XXXX. An alternative product feed will be available to support those who wish to retrieve basic product information (trips, departures, prices).

Summary of changes​

Here is a high-level summary of the REST API changes:

1. Authentication & Standards​

  • API key auth → OAuth 2.0 (Client Credentials) with access tokens
  • Consistent HTTP status codes, error formats, and REST conventions

2. API Structure & Resources​

Intrepid products are now represented by these dedicated resources:

  • trips (supplemented by departures, room-options and trip-notes)
  • accommodations
  • transfers
  • activities (formerly known as “Sightseeing”)
  • additional services

Trips​

  • GET /products has been replaced by GET /trips
  • New structured model (type, subtype, geography, themes, ratings, images, URLs)
  • Content significantly richer and more normalized
  • Some trip fields moved to departures, room options, or itineraries

Departures​

  • Departures can be fetched using GET /departures and optionally filtered by tripId or tripCode
  • Location data enhanced (e.g. latitude/longitude, timezone)
  • Pricing and availability relocated to room options resource

Room Options (New)​

  • Room options is a new resource representing the different options available to be booked for a departure
  • Accessible via GET /departures/{departureId}/room-options

Pricing Model​

  • Prices are no longer a standalone resource and instead are embedded directly into bookable products (room options, accommodations, etc.)
  • Pricing includes promotions and conditional pricing (e.g. children, multi-passenger) data in addition to the default, publicly available pricing

AddOns & Extras​

  • Accommodations, transfers, activities, and additional services and now represented as distinct resources
  • Each of these products are retrievable by their own API endpoints (e.g. GET /accommodations) and can be filtered by trips where they are bookable
  • “Sightseeing” renamed to Activities across all endpoints

Trip Notes​

  • Now available in the Partner API using GET /trips/{tripId}/trip-notes

g) Bookings & Customers​

  • Booked components (trips, accommodations, transfers, activities) are accessible via bookings e.g. GET /bookings/{bookingId}/trips
  • Customers on a booking are now retrievable by a single endpoint (GET /bookings/{bookingId}/customers) but can be filtered by a booked component

h) Request body, Query parameters and Response body changes​

  • Many Public API / XML fields and parameters have been renamed, moved, or removed
  • Product data is more normalized and nested

How to use this migration guide​

  • This document is designed to help you assess and update your existing integration as you migrate from the Public API / XML Feeds to the Partner Platform APIs.

Approach​

To use this guide effectively, you should review it resource by resource.

Each major resource exposed by the Partner API (e.g. trips, departures, room options, accommodations, transfers, activities, bookings, booked components, and customers) has its own section within this document. These sections summarise how that specific resource has changed compared to the Public API and XML feeds.

Your task is to compare each of these sections with how your integration currently works.

What to look for in each resource section​

As you move through the document, focus on identifying whether any of the following changes apply to your integration:

  • Resource path changes: some resources have been restructured to be retrievable by a different path (e.g. GET /products -> GET /trips)
  • Response changes: fields may have been renamed, removed, restructured, or returned as nested objects or arrays
  • Removed or relocated fields: some data that previously existed in a response may now be present within a different resource, or has been removed entirely
  • Request changes: depending on the resource, there may be changes to required or optional request body fields, supported query parameters, pagination parameters

Not every resource will contain all these change types, but most will include at least response changes or removed/relocated fields. Fields that have been introduced or have changed, are highlighted in green within the document.

How to Determine Whether You Need to Update Your Integration​

For each resource, identify whether your integration uses it, then if it does:

  • Compare the documented changes to your current usage
  • Check which response fields you rely on, which request parameters you send and which paths you use
  • Determine changes that are required (e.g. minor changes may involve renaming fields or updating mappings, larger changes may require restructuring how you fetch related data or how many calls you make)

Outcome​

By progressing through each resource section in this way, you should be able to understand:

  • what has changed in the Partner API
  • whether those changes affect your existing integration
  • what updates are required to migrate successfully