Viator Reservation System API

{
  "openapi": "3.0.0",
  "info": {
    "title": "Viator Reservation System API",
    "x-logo": {
      "url": "resources/img/sapi/Viator_Logo_RGB_Green.png",
      "altText": "Viator",
      "href": "https://www.viator.com"
    },
    "contact": {
      "name": "API Integrations Support",
      "email": "supplierAPI@viator.com"
    },
    "version": "",
    "description": "<style>\n/* ----------------------------------------------------------------------\n   Stripe-inspired look & feel for the Viator Reservation System API docs.\n   Layout (3-panel nav/content/code) is provided by Redoc; this layer adds\n   typography, spacing and accent polish using Viator brand colors.\n   Accent teal #00876A \u00b7 dark code rail #0a2a2e \u00b7 light sidebar #f6f8f8\n   Type matches Stripe's scale (16px/400 body, weight-500 headings) and\n   uses Stripe's own font stack (S\u00f6hne -> system fallback) set in redocly.yaml.\n   ---------------------------------------------------------------------- */\n\n/* Logo: Viator wordmark, top-left of the sidebar (Stripe-style placement) */\nimg[alt=\"Viator\"] {\n    height: 30px;\n    width: auto;\n    max-width: 80%;\n    margin: 16px 0 10px 16px;\n    display: block;\n}\n\n/* Smoother text rendering, closer to Stripe's docs */\nbody,\n.redoc-wrap,\n[data-component-id] {\n    -webkit-font-smoothing: antialiased;\n    -moz-osx-font-smoothing: grayscale;\n    text-rendering: optimizeLegibility;\n}\n\n/* Headings: match Stripe's type scale (weight 500, generous sizes, tight\n   tracking). Scoped to .api-content with !important to win over Redoc's\n   built-in heading sizes. */\n.api-content h1, .api-content h2, .api-content h3,\n.api-content h4, .api-content h5 {\n    font-weight: 500 !important;\n}\n.api-content h1 {\n    font-size: 38px !important;\n    line-height: 48px !important;\n    letter-spacing: -0.02em !important;\n}\n.api-content h2 {\n    font-size: 28px !important;\n    line-height: 36px !important;\n    letter-spacing: -0.018em !important;\n}\n.api-content h3 {\n    font-size: 20px !important;\n    line-height: 28px !important;\n    letter-spacing: -0.012em !important;\n}\n.api-content h4, .api-content h5 {\n    font-weight: 600 !important;\n    letter-spacing: -0.006em !important;\n}\n\n/* Links: teal with a subtle hover underline */\na, a:visited {\n    color: #00876A;\n    text-decoration: none;\n}\na:hover {\n    color: #00694f;\n    text-decoration: underline;\n}\n\n/* Sidebar: light, airy, Stripe-like with a thin divider */\n.menu-content {\n    border-right: 1px solid #e3eae9;\n}\n.menu-content label[role=\"menuitem\"]:hover,\n.menu-content li[role=\"menuitem\"]:hover {\n    background-color: #eef3f2;\n}\n\n/* Active nav item: teal accent bar */\n.menu-content label.active,\n.menu-content li.active > label {\n    color: #00876A;\n    box-shadow: inset 3px 0 0 0 #00876A;\n}\n\n/* Search box: rounded, soft border to match Stripe's input style */\n[role=\"search\"] input,\n.search-input {\n    border: 1px solid #d7e0df !important;\n    border-radius: 8px !important;\n}\n\n/* Center and add border to all images (preserved from original) */\np img {\n    border-radius: 4px;\n    border: 1px solid #ddd;\n    margin-left: auto;\n    margin-right: auto;\n    display: block;\n    margin-bottom: 28px;\n}\n</style>\n\n# Introduction\nThese API specifications detail the technical requirements for integrating operator reservation systems with Viator. This guide is intended for developers and technical teams to ensure a standardized implementation and reliable data exchange.\n\n# Prerequisites\nAccess is restricted to operators registered with Viator and their authorized reservation system providers. Integration workflows may only proceed following technical evaluation and formal approval by Viator.\n\nFurthermore, development **may only commence** if Viator registered operators are using the reservation system. For operator onboarding details, please refer to the [supplier sign-up page](https://supplier.viator.com/sign-up-info).\n\n# Getting Started\nReview the following core components to begin your implementation:\n\n- [What\u2019s new](#tag/What's-new)\n- [Connectivity overview](#tag/Connectivity-overview)\n- [API overview](#tag/API-overview)\n- [Implementation approach](#tag/Implementation-approach)\n- [Frequently asked questions](#tag/FAQs)\n\nAdherence to these specifications is crucial for successful integration, guaranteeing optimal performance, data integrity, and a superior user experience for both operators and Viator customers. \n\nIf at any point you need clarification or help, please don\u2019t hesitate to [contact us here](#tag/Contact-us).\n"
  },
  "tags": [
    {
      "name": "What's new",
      "description": "This section outlines the key updates and new features in the latest version of the Operator Connectivity API specifications:\n\n## Versioning System\nThe Operator Connectivity API now uses versioning for backward compatibility and smoother updates. Existing legacy endpoints are considered version 1.0, while versions of new endpoints begin with 2.0.\n\nTo allow early access and feedback on upcoming endpoints before release, a Beta program has been introduced. This allows partners to evaluate pre-production versions. Review the [Beta](#tag/Beta) section for newly introduced endpoints.\n\nAs new versions of the endpoints are introduced, older versions and endpoints that were replaced are set for deprecation. \n\nReview the [Deprecated](#tag/Deprecated) section for a list of endpoints scheduled for deprecation.\n\n## Authentication Header\nVersion 2.0 and above endpoints now expose the API key on the HTTP headers. Backward compatibility for legacy v1 endpoints continues to be supported, no changes required at this point, but header key authentication is also supported on v1 endpoints.\n\n## Content Type\nVersion 2.0 and above endpoints communicate using the JSON standard. Therefore, the headers \"Content-Type\" and \"Accept\" accept only \"application/json\".\n\nXML (`application/xml`), previously offered on v1.0 endpoints, is now **deprecated** and is not supported for new integrations \u2014 JSON is the only supported format going forward. Existing v1.0 XML integrations continue to work; see the [Deprecated](#tag/Deprecated) section.\n\n## Product Option identification\nA simplified product variant (aka product option) identifier has been introduced to allow reservation systems to define a unique single identifier to identify any product variant. This new identifier is applicable only to v2.0 APIs and **must be returned** in the [Tour List API](#tag/Reservation-system-APIs/operation/tourList). \n\n## Pricing Capabilities\nOne of the most impactful changes with the new version is the introduction of pricing capabilities that support all of Viator's existing pricing models, including per person price, tiered per person price and unit price.\n\n## Notification Webhooks\nVersion 2.0 introduces new Viator hosted endpoints that enable reservation systems to communicate updates to Viator regarding:\n- Salability (availability status)\n- Capacity (remaining seats or spaces)\n- Pricing (current rates)\n- Special Offers (discount merchandising)\n\nThese endpoints ensure that customers always see accurate, current, inventory and pricing as provided by operators through reservation systems. \n\n## Reservation\nVersion 2.0 introduces a new endpoint that allows Viator to request the reservation of inventory and price before the booking is made. In V1.0 inventory was held via the [Real-time Availability API](#operation/availability) request using the AvailabilityHold attribute. In V2.0, this process has moved to the new endpoint that now also expects pricing to be held. \n\n\n## Contract Testing\nFor version 2.0 APIs a contract testing tool is available to help ensure that services are performing according to specification. The tool provides multiple test cases, along with parameters required to perform the tests, for each API. For more information review the Contract Testing Tool section under [Contract Testing](#tag/Contract-testing)."
    },
    {
      "name": "Implementation approach",
      "description": "1. **Project Kick-off Meeting** - Scheduled by Viator technical resources after initial contact with the Supplier. The following should be discussed:\n- Determine Project Team Members\n- Scope of Implementation (capabilities to be supported)\n- Agree on Preliminary Time Lines\n- Determine Project Team Communication Method\n\n2. **Specification Review and Data Mapping** - Reservation systems review API specifications in preparation for development. This step includes:\n- Review of API specifications\n- Mapping API fields to reservation system fields\n- Mapping API product structure\n\n3. **Specification Clarifications** - Reservation system will raise clarifications with Viator. \n- This can be done via email or phone. \n\n4. **API Development** - Reservation system will commence development of the necessary APIs. This includes:\n- Development of reservation system services\n- Development of Viator service requests \n- Contract testing\n\n5. **Test Environment Configuration** - Viator will configure the test environment in preparation for certification testing. This step includes:\n- API configuration \n- Product mapping \n\n6. **Certification Testing** - Reservation system and Viator will conduct various certification tests to ensure APIs are working as expected. This step includes:\n- Agreeing on test products\n- Agreeing on a test schedule\n- Test Execution and reporting (typically over email)\n\n7. **Production Environment Configuration** - Viator will configure the production environment. This step includes:\n- API configuration \n- Product mapping\n\n8. **Go Live** - Viator and reservation system prepare for Go Live. This includes:\n- Schedule Go Live date\n- \"Switch On\" the API, initially for a small number of products\n- Transaction monitoring and issue resolution\n- Roll out all applicable products\n- Sign-off by reservation system and Viator"
    },
    {
      "name": "API overview",
      "description": "Integration with the Viator Reservation System API presents considerable strategic benefits for operators and reservation systems. It substantially enhances distribution and sales capabilities by furnishing Viator with a more comprehensive inventory and real-time transaction capabilities.\n\nAPI integration with Viator is essential for accommodating last-minute bookings, allowing operators to sell remaining inventory until their specified booking cutoff. Furthermore, the API automates availability and pricing synchronization and booking transactions that lead to higher accuracy and reduced operator overhead.\n\nThe API's primary functionalities encompass:\n- Pricing and availability synchronization with capacity administration\n- Departure time synchronization\n- Booking reservation and confirmation\n- Post-booking transaction automation \n\nAdditional advantages of API integration include:\n\n- Streamlined Reconciliation: The Viator booking confirmation number is sent to the operator's reservation system via API. This number, along with the operator's confirmation or order number, is displayed on Viator customer vouchers/tickets, allowing for booking reconciliation within the operator's reservation system.\n\n- Barcode Compatibility: The API allows reservation systems to generate barcodes that can be integrated into Viator customer paper or smartphone vouchers/tickets. This functionality is particularly important for operators who use barcode scanners for activity entry.\n\n- Product Identification: Viator customer vouchers display the operator's product identifiers, which are correlated with Viator's own identifiers. This correlation allows operators to have a clearer identification of the product purchased by the customer.\n\n\n## Introduction\nThis section provides details pertaining to the API supported business processes, security, communication, testing, and implementation.\nAchieving integration with Viator requires the use of both Viator and supplier built APIs:\n\n- [Reservation System APIs](#tag/Reservation-system-APIs): Services developed by the reservation system / booking software and consumed by Viator.\n- [Viator APIs](#tag/Viator-APIs): Services developed by Viator and consumed by reservation systems / booking software.\n\nThis document provides detailed specifications for each service along with testing tools and migration guides, establishing a standard for integration with Viator.\n\n## Supported processes\nThe Viator Reservation System APIs have been designed to support a number of business processes, these include:\n\n- **Product validation and mapping** - supported by the [Tour List API](#operation/tourList).\n- **Price and availability synchronization** - supported by the [Availability and pricing](#tag/Connectivity-overview/Availability-and-Pricing) APIs.\n- **Special Offer Merchandising** - supported by the [Special Offers API](#operation/specialOffers) and [Special Offers Notification Webhook](#operation/specialOffersNotification)\n- **Reservation and booking** - supported by the [Reserve](#operation/reserve) and [Booking](#operation/booking) APIs.\n- **Post booking transactions** - supported by the [Booking Amendment](#operation/bookingAmendment) and [Booking Cancellation](#operation/bookingCancellation) APIs.\n- **Redemption verification** - supported by the [Redemption API](#operation/redemption). \n\n## Security\n\nAll APIs will use the **Hypertext Transfer Protocol Secure** (HTTPS). \n\nAuthentication is achieved by the use of **API keys**, supplied within the header (v1.0 and v2.0 endpoints) or the payload (v1.0 endpoints only) of each request. A unique API Key is assigned for each Operator account. \n\n## Webservice architecture\n\nThe Viator Reservation System APIs support **RESTful** architecture. **JSON (`application/json`) is the only supported format for new integrations.** **XML (`application/xml`) is deprecated** \u2014 it remains available for existing v1.0 integrations only, will receive no further updates, and is scheduled for eventual retirement. All v2.0 endpoints are JSON-only. See the [Deprecated](#tag/Deprecated) section for details.\n\nAll RESTful APIs use **POST** methods only, **GET, DELETE, PUT, etc.** methods are NOT currently supported. The message body of the POST request/response will include the payload described in this document."
    },
    {
      "name": "Connectivity overview",
      "description": "The following sections detail the operational impact of integration and endpoints on overall connectivity, operator processes, and customer experience.\n\nThe API structure is organized into three primary categories:\n\n- [Catalog operations](#tag/Connectivity-overview/Catalog-operations)\n- [Availability and pricing](#tag/Connectivity-overview/Availability-and-Pricing)\n- [Booking operations](#tag/Connectivity-overview/Booking-operations)\n- [Booking redemption](#tag/Connectivity-overview/Booking-redemption)\n\n## Catalog operations\n### Tour list\n\nThe [Tour List API](#tag/Reservation-system-APIs/operation/tourList) streamlines the mapping of an operator's reservation system inventory (products and product options) to Viator's equivalent. These mapped values are then used in subsequent transaction requests, where Viator transmits requests using the reservation system's identifiers.\n\nThe details returned in the Tour List API are surfaced in the **Product Connection** tab of the Viator supply center to facilitate accurate inventory mapping between the two systems. \n\nMapped inventory **must** have capacity (available for sale). If a product cannot be mapped, there is likely a problem with the Tour List API response or with the inventory capacity (not available for sale, issue with availability API\u2019s response). The technical team at the reservation system is typically better equipped to resolve such scenarios. \n\n## Availability and Pricing\n**Support for the following APIs is a mandatory integration requirement**, highlighting their fundamental role in efficient inventory and pricing management for operators, and overall impact to the customer booking experience. \n\nIntegrating our comprehensive suite of availability and pricing APIs revolutionizes how operators manage availability and pricing of their inventory, significantly reducing the need for tedious manual updates within the management center. This powerful collection includes a set of distinct APIs, each tailored to streamline specific aspects of the operations and customer experience:\n\n- [Calendar API](#tag/Reservation-system-APIs/operation/calendar) (v2.0) - Empowers Viator to access and retrieve long term availability, pricing and special offer (promotions) information from the reservation system. This allows Viator customers to view available dates and prices on the product details page calendar. For operators, these APIs automate the regular updates of availability, pricing and special offers, eliminating the need for manual intervention through the Viator supply center. This API replaces both the Batch Availability and the Batch Pricing APIs (both of which are v1.0).\n\n- [Availability Check API](#tag/Reservation-system-APIs/operation/availabilityCheck) (v2.0) -  Designed for real-time usage through the booking flow, this API enables Viator to verify capacity (availability for sale) in real-time throughout the customer\u2019s progression through the booking funnel. This ensures that customers always see the most current availability and pricing information, preventing overbookings, erroneous customer charges, encouraging last minute bookings and enhancing the overall customer experience. This capability is crucial for supporting operators' dynamic, fluctuating pricing strategies and responding instantly to market demands. This API replaces the Real-time Availability API (v1.0).\n\n- [Event Notifications](#tag/Viator-APIs/operation/eventNotification) (v2.0) - This critical endpoint hosted by Viator provides reservation systems the ability to notify Viator when changes are made to pricing, or when changes occur to capacity and availability. This not only ensures Viator\u2019s pricing always reflects the operator\u2019s desired price, it enables Viator to allow or prevent overbookings, and it is especially important to drive bookings for last minute availability. \n\n- [Special Offer Notifications](#tag/Viator-APIs/operation/specialOffersNotification) (v2.0) - This endpoint allows for the notification of new or updated Special Offers to Viator, ensuring that Viator accurately merchandises discounted inventory. The updates provide merchandising signals for customers, increasing the visibility of the offers and thereby boosting bookings.\n\n- [Special Offers API](#tag/Reservation-system-APIs/operation/specialOffers) (v2.0) - Retrieves the Special Offers metadata required for Viator to accurately apply special offer rules and provides operators with visibility into the merchandising signals associated with their inventory. \n\nBy leveraging these APIs, you can automate a significant portion of operational tasks, leading to improved accuracy, reduced operational overhead, and a more responsive and efficient system for managing availability, pricing and special offers. This automation not only streamlines operators\u2019 internal processes but also enhances the customer experience by providing up-to-date and reliable information.\n\n## Booking operations\nThe following booking operations APIs are available and, with the exception of the booking amendment API, **are mandatory to support**:\n\n### Reserve\nThe [Reserve API](#tag/Reservation-system-APIs/operation/reserve) (v2.0) is designed to hold inventory and price for a booking. \n\nThis API supersedes the InventoryHold function previously available in the Real-time Availability API (v1.0). Viator requires reservation systems to hold inventory for a specific duration, facilitating a seamless customer experience by allowing adequate time for payment completion during checkout. This mechanism helps operators avoid overbookings while also preventing inventory from being held unnecessarily. Reservation systems are encouraged to release previously reserved inventory if a booking is not confirmed within a predefined duration.\n\nThis API must only be used in combination with [Availability and Pricing](#tag/Connectivity-overview/Availability-and-Pricing) v2.0 APIs. \n\n### Booking\nThe [Booking API](#tag/Reservation-system-APIs/operation/booking) creates a booking in the operator's reservation system upon successful customer payment. This transmission finalizes the booking process.\n\nOperators are not notified via email when a booking is successfully transmitted by the API. However, if an API booking attempt is unsuccessful, the booking fallback process is initiated, which then notifies operators of bookings via email.\n\n### Booking Amendment\nThe [Booking Amendment API](#tag/Reservation-system-APIs/operation/bookingAmendment) allows changes to confirmed bookings to be sent to the operator\u2019s reservation systems. Customers can request booking amendments after payment and booking confirmation, but before travel.\n\nPermissible amendments:\n- Lead traveler's name\n- Traveler mix\n- Travel date\n- Hotel details\n- Tour option\n\nOperators will receive booking amendment email notifications only if an API booking amendment attempt is unsuccessful. Successful API booking amendments do not generate email notifications for operators.\n\n### Booking Cancellation\nThe [Booking Cancellation API](#tag/Reservation-system-APIs/operation/bookingCancellation) streamlines the cancellation and refund process for confirmed bookings. It automates the cancellation request by transmitting it directly to the operator's reservation system. This not only minimizes administrative tasks for operators but also guarantees precise inventory representation, facilitating the resale of tickets.\n\nOperators will receive booking cancellation email notifications only if an API booking cancellation attempt is unsuccessful. Successful API booking cancellations do not generate email notifications for operators.\n\n## Booking redemption\nThe [Booking Redemption API](#tag/Reservation-system-APIs/operation/redemption) provides Viator visibility into the redemption status of a confirmed booking at the time a customer makes a cancellation request to ensure refunds are processed accordingly. "
    },
    {
      "name": "API configurations",
      "description": "## Integration configuration\nConfigurations must be determined and applied to both Viator and reservation systems to enable communication via the APIs. The following configuration items must be determined during the project initiation phase:\n\n- **Integration capabilities** - provided by the reservation system, these are the APIs supported by the reservation system (including mandatory APIs).\n- **Reservation system endpoints** - provided by the reservation system for each of the services supported.\n- **Supplier ID** - provided by Viator in preparation for testing, the `SupplierId` uniquely identifies an operator in Viator systems\n- **Reseller ID** - provided by Viator (for v1.0 APIs only) in preparation for testing.\n- **API key** - provided by Viator in preparation for testing and Go Live. The API key is used for authentication\n\n## Product mapping\nViator systems will make API requests to the reservation systems using the reservation system\u2019s product identifiers. The reservation system\u2019s product identifiers are typically provided to Viator via the [Tour List API](#operation/tourList). These are mapped to Viator products so that subsequent transactions utilize the reservation system product identifiers.\n\nThe API supports multiple fields that can be used to identify products and product options (aka product variants), i.e., a product option typically has either different pricing or inventory levels from other options of the same product.\n\nIn the APIs the following fields can be used as identifiers of products and/or product options. The supplier determines which of the below fields it needs to use to correctly interpret what product or product option an API request is for.\n\n* `SupplierProductCode` \u2013 this is the only mandatory product identification field in Viator APIs. It is meant to be used for a code (key) that uniquely identifies a product.\n    * **Note**: this field has a maximum length of 50 characters or less and must not include the pipe (`|`) character; product codes longer than this will fail.\n* `SupplierOptionCode` \u2013 this field is optional. It is used when a product has multiple options, it identifies an option (or a variant) of the product.\n* `Name/Value` - a max of four key/value pairs can optionally be used in conjunction with the `SupplierOptionCode` to uniquely identify a product variant. These appear under the `Option` element in the APIs. Similar to `SupplierOptionCode` they can be used to identify an option. \n* `productOptionId` - this field has been introduced with v2.0 and is applicable only to v2.0 APIs. It is a single identifier for the product variant. This identifier will in the future replace `SupplierOptionCode` and `Name/Value` fields.\n\n## Pricing rates mapping\n\nViator currently only supports a limited group of pricing rates: Adult, Child, Youth, Infant and Senior. Reservation Systems and operators may support other pricing rates.\n\nWe recommend the following mapping of various pricing rates to Viator supported options.\n\n| **Reservation System Price Rates** | **Viator Price Rates** |\n|----------------------------------------|--------------------------------------|\n| Adult                                  | Adult                                |\n| Child                                  | Child                                |\n| Youth                                  | Youth                                |\n| Infant                                 | Infant                               |\n| Senior                                 | Senior                               |\n| Concession                             | Senior                               |\n| Veteran                                | Senior                               |\n| Pensioner                              | Senior                               |\n| Student                                | Youth                                |\n| Teenager                               | Youth                                |\n| Toddler                                | Infant                               |\n| Baby                                   | Infant                               |\n| Everyone                               | Adult                                |\n| Other                                  | Adult                                |\n| Family Price.                          | **Not Supported**                    |\n\nViator also supports the concept of unit pricing. For products priced in this manner the following is recommended:\n\n| **Reservation System Price Rates** | **Viator Price Rates** |\n|----------------------------------------|--------------------------------------|\n| Car                                    | Unit                                 |\n| Boat                                   | Unit                                 |\n| Vehicle                                | Unit                                 |\n| Group                                  | Unit                                 |\n\n## Booking Cut-off\nThe booking cut-off value is a time, prior to a sellable item's start time, after which booking may no longer be accepted by the reservation system; for example, a particular tour might not accept bookings if it is less than 24 hours before the start time.\n\nFor connected products, this value is provided to Viator via the `bookingCutoff` element of the [Availability and pricing](#tag/Connectivity-overview/Availability-and-Pricing) API responses.\n\n#### BookingCutoff Usage\n\nThe `bookingCutoff` will be used to prevent bookings from taking place after the time specified in the `bookingCutoff`. It is also used to inform customers how long they have left before a booking cut-off restriction prevents them from booking. This aims to both drive customers to make a purchase and improve the customer experience by minimizing unexpected booking failures."
    },
    {
      "name": "SLAs",
      "description": "## Uptime\n**Viator** and integrated **reservation systems** must guarantee a target API availability of:\n\n- For critical, synchronous APIs like Real-Time Availability and Booking and also for Viator Inbound APIs expected target of **99.8%**. It will be an acceptable target of 99.5%.\n- For APIs where usage is asynchronous (e.g., batch data synchronization) and therefore the business impact of temporary availability loss is less severe compared to synchronous booking operations, a target of **99.5%**. It will be an acceptable target of 99%.\n\n## Latency\nViator's proposal acknowledges that APIs used in **real-time** are inherently more critical and thus require **stringent (tighter) latency targets**.\nConversely, **data-sync APIs** can be assigned **more relaxed latency targets**, reflecting their lower impact on immediate user interaction and conversion. \nThe following table presents the latency targets, broken down by APIs.\n\n| **APIs**                                                  | **Expected P90** (secs) | **Acceptable** (secs) | **Longest Allowed** (secs)|\n|-----------------------------------------------------------|-------------------------|-----------------------|---------------------------|\n| Availability Check                                        |          < 1            |           3           |            10             |\n| Reserve                                                   |          < 1            |           3           |            28             |\n| Booking (includes amendment, redemption and cancellation) |          < 5            |           10          |            28             |\n| Calendar                                                  |          < 5            |           10          |            20             |\n| Tourlist                                                  |          < 10           |           15          |            60             |\n\n\nFor Viator inbound APIs the latency targets are:\n\n| **APIs**                            | **Expected P90** (secs) | **Acceptable** (secs) |\n|-------------------------------------|-------------------------|-----------------------|\n|Event Notification API Beta          |          < 1            |          2            |\n|Special Offers Notification API Beta |          < 1            |          2            |\n\n## Error Rate\nThe following table describes the API Types and the respective maximum error rates.\n\n| **API type**                                            | **Maximum acceptable error rate** (Monthly) |\n|---------------------------------------------------------|---------------------------------------------|\n|Availability Check                                       |                 < 1.5%                      |\n|Reserve                                                  |                 < 1.5%                      |\n|Booking(includes amendment, redemption and cancellation) |                 < 0.75%                     |\n|Calendar                                                 |                 < 1%                        |\n|Tourlist                                                 |                 < 0.5%                      |\n\nFor Viator inbound APIs the error targets are:\n\n| **API type**                       | **Maximum acceptable error rate** (Monthly) |\n|------------------------------------|---------------------------------------------|\n|Event Notification API Beta         |                  < 0.5%                     |\n|Special Offers Notification API Beta|                  < 0.5%                     |\n\n\n## Throughput\nTo ensure system stability, Viator and the Integrated Reservation System agree to the following throughput limits. These are calculated based on the total number of connected products to ensure the infrastructure scales alongside the business.\n\n### Throughput Calculation Logic\nCapacity is determined by a **Product Multiplier (X)**, defined as:\n- X = Total number of connected products, divided by **10,000** (rounded up to the nearest ten thousand).\n- **Minimu

# --- truncated at 32 KB (456 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/viator/refs/heads/main/openapi/viator-reservation-system-api-openapi.json