Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Resolving Viator API Integration: Manual Availability Blocking and Certified Partner Reassessment

What Was Done

After reviewing the Viator support ticket (t-ad4b92d7) and the reply from James Jimenez at Viator, we identified a critical gap in their API offering: Viator does not provide direct iCal export or webhook-based calendar sync for suppliers. Their only supported integration path requires connecting through a certified channel manager in their dashboard connectivity layer. This created an immediate calendar synchronization problem for May 30, which needed manual blocking, and required reassessing our multi-channel strategy.

Technical Details: Viator's Connectivity Architecture

Viator's supplier integration model is dashboard-only. Their official response indicated that calendar synchronization happens exclusively through:

  • Account Settings → Connectivity → Connect Now — the dashboard interface where suppliers authorize third-party channel managers
  • Certified API partners only — pre-approved integrations (primarily paid channel managers like Bókun, FareHarbor, Rezdy)
  • No self-serve iCal endpoint — Viator does not expose a calendar feed URL that can be polled independently by custom systems
  • No direct webhook support — no event-based notifications when bookings change or availability updates

This architecture choice prioritizes channel control and partner revenue-sharing over operational flexibility. The implication: you cannot build a direct, unmediated calendar sync without going through one of their certified partners.

Immediate Fix: Manual Availability Blocking on supplier.viator.com

Since May 30 needed to be blocked immediately and the iCal sync from Google Calendar was showing it as AVAILABLE, we executed a manual block via the Viator supplier dashboard:

Path: supplier.viator.com → Product 5653407P1 → Availability Tab
Action: 
  1. Locate May 30 in calendar view
  2. Click date → select "Blocked" or "Unavailable" state
  3. Confirm and save
Result: May 30 marked unavailable for all timeslots

The reason this was necessary: the "Availability updated automatically" banner indicates an active iCal sync (likely via Google Calendar integration), but there was a synchronization lag or the date wasn't included in the last polling cycle. Manual blocking ensures immediate enforcement while we address the root cause.

Investigating the Bókun Connection

During review, we discovered that the product connection panel showed Status: Connected (to Bókun). This explained both why availability was syncing and why we had a connectivity dependency we no longer wanted. To disconnect:

Path: supplier.viator.com → Product 5653407P1 → Connectivity Tab
Action:
  1. Locate Bókun connection in the connection panel
  2. Click "Edit" button (top-right of panel)
  3. Select "Remove" or "Disconnect" option
  4. Confirm removal
Result: Bókun sync disabled; availability now managed purely via Viator dashboard

This disconnection was necessary because:

  • Bókun is a paid channel manager (charges operators ~6-8% of booking value)
  • Keeping it connected creates a sync dependency that makes it harder to evaluate alternative pathways
  • May 30 blocking issue suggested Bókun wasn't reliably reflecting manual availability changes

Architecture Decision: Why Viator Integration Failed

The original assumption was that Viator would expose calendar data via iCal or API webhooks, allowing us to build a custom polling/sync layer in our own infrastructure. This would have looked like:

Customer booking → Jada internal system → iCal feed/webhook → Viator supplier calendar

Instead, Viator's actual model is:

Customer booking → Jada internal system → Certified Channel Manager (Bókun, FareHarbor, etc.)
                                        → Viator supplier calendar

This forced intermediary is a business constraint, not a technical one. The certified partners act as a gating layer, which:

  • Prevents direct API access for cost control (they want partner revenue)
  • Centralizes booking flow through managed integrations
  • Adds friction but ensures compliance with their booking terms

Available Paths Forward

We have two realistic options:

Option 1: FareHarbor (Operator-Friendly Pricing)

FareHarbor is the only certified Viator partner with a fee structure that doesn't penalize operators:

  • Guest-side fee: ~6% (FareHarbor's commission, not charged to you)
  • API access: Available for building custom integrations
  • iCal export: Supported; you can pull calendar feeds directly
  • Cost to operator: $0 (unless you need premium features)

Option 2: Undocumented iCal Feed (Lower Probability)

Some suppliers have reported finding undocumented calendar feeds in Viator's system. Before committing to FareHarbor, we should send a targeted follow-up email to James Jimenez:

Subject: Re: Viator API Integration — iCal Feed Question

James,

Thanks for the response on certified partners. Quick follow-up:

Does Viator expose an iCal calendar URL for confirmed supplier bookings 
that our system can poll directly? (Not through the dashboard sync, but 
an actual feed endpoint.) Some operators have mentioned finding this.

If that exists, we could manage availability synchronization without 
needing a channel manager intermediary.

Thanks,
[Name]

This email is sharper than the original request — it's specific to iCal feeds rather than open-ended API questions. Viator's support may reveal an undocumented endpoint worth exploring.

Key Decisions

  • Manual blocking over waiting for sync: May 30 needed immediate enforcement; relying on iCal polling would have risked overbooking
  • Disconnect Bókun before choosing alternatives: Keeping a dependency active makes it harder to evaluate clean options; removing it first clarifies the landscape
  • FareHarbor as the fallback: If the iCal feed angle fails, FareHarbor's pricing model aligns with operator economics (guest-side fee only, no operator margin cut)
  • One more targeted email: Worth 24 hours to see if Viator has an undocumented solution before committing to any paid integration

What's Next

  • Send follow-up email to James Jimenez asking specifically about iCal feed availability (not generic API access)
  • Wait 48 hours for response — typical SLA for Viator support
  • If no iCal feed: Evaluate FareHarbor onboarding and API documentation; estimate integration effort for calendar sync layer
  • Monitor May 30 availability on supplier.viator.com after manual block to confirm enforcement
  • Document decision in the internal integration runbook with the constraint: Viator requires certified partner intermediary; direct API access not available