← Back to Operator Partnership OverviewAPI-Only Direct Partnership Onboarding

Operator API Onboarding & Integration Verification

“It’s time tour operators kept more of every booking. Connect your existing booking system to DCC through an authorized API. Our commission is 10% on completed direct bookings we generate.”

Direct partnerships are API-only. Without an authorized API connection, we cannot switch an operator to direct bookings, and any existing verified Viator listings can continue through Viator. Submitting an onboarding application initiates technical and commercial review—it never automatically authorizes sales.

Step 1 · Operator Application (No API Secrets Collected Here)

Submit Company, Booking System & API Documentation Details

We welcome operators worldwide. Please provide your company contact details, destinations, reservation system, and API documentation link.

Security & Commercial Notice: Do not enter API keys, tokens, or secrets in this form or send them by email. Credentials are arranged securely after technical review and signed commercial terms. Submitting this application does not automatically authorize sales; existing verified Viator listings remain active on Viator until a direct integration passes all verification gates.

Company Name *

Official Company Website *

Contact Name & Role *

Business Email *

Destinations Served *

Booking System *

API Documentation URL / Specification Reference *

Authorized API Access Confirmation: Our company has (or can authorize) provider-approved API access for our booking system. (Direct partnerships are API-only; without an API connection, we cannot switch bookings to direct and existing verified listings can continue through Viator.)Operator Permission & Commercial Terms Separation *: I confirm I have operator permission to submit this application for technical review, and I understand the proposed 10% commission on completed direct bookings is separate from signed commercial and settlement terms (submitting this form does not authorize sales until commercial terms are signed and technical verification passes).

Notes on Product Catalog or Policies (Do NOT include API keys or secrets)

Step 2 · Mandatory Verification Gates Before Channel Cutover

Required Verification Before Switching from Viator to Direct API

We keep an operator's existing verified Viator booking channel active until all seven verification gates pass. Commission never determines traveler suitability or recommendation ranking.

1. Operator Permission

Explicit authorization from the tour or transportation company.

2. Agreed Commercial & Settlement Terms

Signed 10% direct commission and settlement agreement (kept separate from onboarding applications).

3. Securely Arranged Credentials

Provider-approved API credentials arranged securely after review—never via public forms or email.

4. Exact Product & Option Mapping

Verified mapping between DCC references and the operator's native API product/option IDs.

5. Current Prices & Live Availability

Live API responses verified for real-time seat inventory, schedules, and retail pricing.

6. Reliable Attribution & Outcome Reporting

End-to-end verification of booking references, confirmations, cancellations, and settlement reporting.

7. Cancellation & Cruise-Return Policies

Verified separately for direct bookings; Viator marketplace guarantees do not automatically carry over.

First Direct-Channel Pilot Candidate (Rezdy API) — Distinct from GoSno's Existing Storefront

GoSno · Rezdy Native REST API v1

Inspect GoSno Pilot Profile →

GoSno operates its own Rezdy-backed private transfer checkout on gosno.co and publishes a live /.well-known/dcc manifest. Separately, GoSno is the first candidate for DCC's 10% direct-channel API pilot. While gosno.co's own storefront endpoints respond in production, DCC-side Rezdy API credential provisioning, DCC-side live bookable slot verification, and the 10% commercial addendum remain pending.

1 · Existing GoSno Storefront Integration (gosno.co — Operational & Unchanged):Operational on gosno.co: GoSno's own storefront checkout (gosno.co/denver-to-breckenridge), /.well-known/dcc manifest, and /api/dcc/routes catalog are active in production for private transfers.Captured live: GET /.well-known/dcc (HTTP 200) · GET /api/dcc/routes (HTTP 200, 9 private SUV routes) · GET /api/availability (HTTP 200, suv.available=false, van.quoteOnly=true)

2 · New DCC 10% Direct-Channel Pilot (DCC-Side Verification — Pending):All DCC-side pilot gates (operator authorization, DCC-provisioned Rezdy API credentials, DCC-side product mapping, live price/availability queries inside DCC, 10% commercial addendum, and settlement reporting) remain pending until DCC-side integration credentials and end-to-end tests are completed.

Inspected Provider Documentation

Provider-Specific API Architectures (Not All Systems Use OCTO)

We inspect the actual API documentation for each booking system rather than assuming FareHarbor, Bókun, Rezdy, and other native APIs all use OCTO endpoints.

Rezdy (Supplier / Agent REST API v1)

Native REST JSON (v1)

Auth: apiKey header / query parameter issued per authorized supplier/agent connection

GET /v1/products, GET /v1/availability?productCode=...&startTimeLocal=...&endTimeLocal=...

POST /v1/bookings with internal reference/reseller tracking; used by GoSno's gosno.co storefront and evaluated as DCC's first direct-channel pilot candidate.

FareHarbor (External API v1)

Native REST JSON (External API v1 — NOT OCTO by default)

Auth: X-FareHarbor-API-App and X-FareHarbor-API-User headers with operator-authorized company shortname

GET /api/external/v1/companies/{shortname}/items/, GET .../items/{pk}/availabilities/date/{date}/

POST .../availabilities/{pk}/bookings/ with partner/affiliate voucher & note fields; requires explicit operator permission for the company shortname.

Bókun (REST API / Channel Inventory API)

Native REST JSON with HMAC-SHA1 request signing (separate from optional OCTO adapter)

Auth: X-Bokun-Date, X-Bokun-AccessKey, and X-Bokun-Signature (HMAC-SHA1)

GET /activity.json/{id}, GET /activity.json/{id}/availabilities?start=...&end=...

POST /booking.json/activity-booking/reserve-and-confirm with externalBookingReference for commission settlement.

Ventrata / OCTO Core v1.2.0

OCTO Core REST JSON (for providers that explicitly implement OCTO)

Auth: Authorization: Bearer <token> with Octo-Capabilities header

GET /suppliers, GET /products, POST /availability

POST /bookings (hold) and POST /bookings/{uuid}/confirm with resellerReference for outcome reporting.