Reseller API Overview

This page is a capability map of the Travel Curious Reseller API. Each section summarizes what a module does, what to pay attention to, and where to find the full details. If you are working through an integration for the first time, read Transaction Flow alongside this page - it shows the required call order and worked examples.

The requests and responses use a versioning scheme (e.g., targeting the /v1.2 or /v1.3 base path) and a simple custom headers authentication scheme, which needs to be included. The necessary authentication keys will be provided to you as part of the onboarding process.

Travel Curious connects Resellers to Suppliers through a channel binding process. Channel binding is a commercial agreement that makes a Supplier's products visible to your API requests. If you are not seeing the Suppliers or Products you expect, contact your Travel Curious Integration Manager.

The Core API Modules

Suppliers

The Suppliers endpoints return information about the operators connected to your account - their name, location, business hours, contacts, and accepted traveler types. You can retrieve all Suppliers bound to your channel or look up a specific one by ID. To optimize performance and minimize payload overhead, Travel Curious recommends filtering queries using the specific Supplier ID whenever possible.

🔗 Find the full details here: Retrieve Suppliers

Products

Each Supplier exposes one or more bookable Products - museum entries, river cruises, walking tours, shows, and more. The Product object includes a description, location, hours of operation, delivery format and product type details. Products carry a supplier_id, which links them back to their parent Supplier and is required in all downstream calls. Retrieve all Products for a Supplier or fetch a specific one by ID.

🔗 Find the full details here: Retrieve Products

Rates & Price Schedule

Rates define the bookable options within a Product. A single Product may have multiple Rates - for example, a morning session and an afternoon session, each with separate capacity

Every Rate has a type that governs its inventory logic:

• RESERVED: Requires a specific date and time selection. Availability is capacity-bound.
• FREESALE: No fixed capacity; available during the operator's open hours. Only returned in availability when a rate_id is specified.
• PASS: Multi-use or open-dated access, valid across more than one product or date.

The Rate also carries valid.from and valid.until dates defining when it can be booked, and hours defining when the experience operates. These are distinct: valid controls when a booking can be placed; hours describes when the guest actually attends.

Pricing: Each Rate has a static prices[] array for each traveler type. However, these static prices are superseded whenever a matching price exists in the Price Schedule. Always check the Price Schedule first, and fall back to the Rate's static prices only when no scheduled price is available for the requested date, Rate, and traveler type.

🔗 Find the full details here: Retrieve Rates and Fetch Price Schedule

Booking Questions v1.3 : Rates may also carry a bookingQuestions[] array. When present, this means the Supplier requires specific guest information before confirming the booking - for example, dietary needs, pickup preferences, or eligibility data. Always retrieve the full Rate object before building a checkout flow and check whether questions are present. See Booking Questions for how to handle and submit them.

Availability

The Availability endpoints let you check real-time capacity and bookable time slots for a specific Product and Rate. Two endpoints are available:

• List availabilities - Returns all available slots within a date range, useful for building a calendar view.
• Check single availability - Validates availability at a specific at time and quantity, useful immediately before placing a Hold.

Availability responses include capacity (remaining spots) and maxCapacity (total configured). For FREESALE rates, availability is only returned when a rate_id is specified. Availability data expires; use the expires timestamp in the response to know when to refresh.

🔗 Find the full details here: Retrieve Availabilities

Holds

A Hold temporarily reserves inventory while a guest completes checkout. Implementing the Hold is mandatory, but not always mandatory to send a Hold before a booking is created.

The Hold remains active until it expires, or until you explicitly release it with a DELETE /holds/{hold_id}. Releasing holds when a guest abandons their cart is strongly recommended to free capacity for other customers.

Hold expiry times are agreed between the Supplier and Reseller at the time of channel binding. Ensure you know the configured window and surface it appropriately in your checkout flow.

Booking Questions v1.3 : If a Rate has bookingQuestions[] where phase = hold, those answers must be included in the Hold request body. Required questions (required = true) could cause the Hold to fail if omitted. See Holds, Bookings & Cancellations for the answer format.

🔗 Find the full details here: Manage Holds

Bookings & Cancellations

A Booking converts a Hold into a confirmed reservation. The Booking request must include the holdId from the preceding Hold response, along with the customer's details and a traveler object for each item (recommended but not mandatory). Travel Curious validates that the Booking request matches the Hold exactly - the supplierId, rateId, priceId, and traveler count must be identical. Any discrepancy causes the Booking to fail.

On success, the response includes a bookingId, status (OPEN), and - depending on the Supplier - ticket or voucher data. Use the GET /bookings/{booking_id} endpoint to retrieve booking details at any point.

Cancellations require the bookingId and can have a reason code (CUSTOMER, SUPPLIER, FRAUD, or OTHER). Note that cancellations are only available when the Rate's cancelable flag is true. For non-cancelable products, manual coordination between Supplier and Reseller is required.

Booking Questions v1.3 : Questions where phase = booking must be answered in the Booking request body, not the Hold. Required questions (required = true) could cause the Booking to fail if omitted. See Holds, Bookings & Cancellations for details.

🔗 Find the full details here: Manage Bookings

New Capabilities

Content New in v1.3

v1.2 partners: This section describes a v1.3-only capability. Your existing integration is unaffected. You can adopt it at any time by switching to the /v1.3/ base path.

The Content object provides structured, customer-facing descriptive data that can be attached to Suppliers, Products, Rates, and individual Rate Prices. It carries localized text in multiple formats, rich media assets, feature highlights, FAQs, aggregate ratings, and individual reviews - all in a single consistent structure, separate from the transactional fields.

Content is not returned by default. To include it, add content=true to the following singular GET requests:

GET /v1.3/suppliers/{id}content=true

GET /v1.3/suppliers/{id}/products/{id}content=true

GET /v1.3/suppliers/{id}/products/{id}/rates/{id}content=true

Content is not available on list endpoints. Use the optional locale= parameter to filter returned text by language (e.g., locale=en-US,es-ES).

The Content object includes: name, title, subtitle, description, shortDescription, categories, duration, features, faqs, media, ratings, reviews, and metadata. All text fields use the LocalizedTextSet format - an array of { text, locale, format } objects supporting plain, html, and markdown.

When content is present in a response, its values must take priority over the equivalent standard entity fields (such as name, description, title) for display purposes. Fall back to the standard fields only when a specific content field is absent.

🔗 Find the full details here: Content

Booking Questions New in v1.3

v1.2 partners: This section describes a v1.3-only capability. Your existing integration is unaffected. You can adopt it at any time by switching to the /v1.3/ base path.

Some products require specific guest information before a booking can be confirmed. v1.3 introduces a structured BookingQuestions capability that formalizes how this data is collected - with typed validation, localized question text, dependency rules, and clear submission phases.

Where questions come from: Questions are returned as part of the Rate object. Booking Questions should be returned on both the singular and plural GET rates endpoints.

Scope controls who the answer applies to:

• booking - One answer covers the entire booking (e.g., preferred pickup location)
• guest - One answer is required per traveler (e.g., dietary requirement, passport number)

Phase controls when the answer must be submitted:

• hold - The answer must be included in the Hold request. Required hold-phase questions will cause the Hold to fail if omitted.
• booking - The answer must be included in the Booking confirmation request.

Answer types supported: text, email, phone, integer, decimal, boolean, choice, multiple_choice, date, time, datetime. For choice and multiple_choice questions, use the answer value from the matching AnswerOption .

Additional question properties to implement:

• required - If true, the question must be answered or the request could fail.
• pii - If true, the answer contains Personally Identifiable Information (e.g., passport numbers, birth dates). Apply appropriate data handling and do not log or cache PII beyond what is operationally necessary.
• dependency - Makes a question conditional on another question's answer. Only render and submit a dependent question if its condition is met.
• constraints[] - Validation rules applied to the answer (e.g., character limits, numeric ranges).

Answers are submitted as a BookingAnswers array - a list of { questionId, answer} pairs - included in the Hold or Booking request body, depending on each question's phase.

🔗 Find the full details here: Booking Questions

Partner-Specific Integrations

Extension Maps

Extension maps (ext or extensions) are key-value containers present throughout the API - on Suppliers, Products, Rates, Availabilities, Hold items, Booking items, and more. They allow Travel Curious, Resellers, and Suppliers to exchange additional information that does not fit within a pre-defined field. Their usage and expected keys vary by Supplier.

Implementing extension map consumption is highly recommended and sometimes can be mandatory. Certain Suppliers, including Disney, Ticketmaster, and Broadway Inbound, require specific extension keys to be present in Hold and Booking requests, and return important operational data in extension fields on responses. Failing to implement them may result in failed bookings or incomplete guest data.

Note: Extension maps and Booking Questions serve different purposes. Extension maps are for unstructured, partner-specific data. Booking Questions are for formal, supplier-mandated guest information with typed validation.

🔗 Find the full details here: Extensions