Operators who already run their own booking software face a specific integration decision when joining Tours Hub: do you manage availability in two places manually, or do you connect your existing system to the platform so that inventory moves in sync? For operators doing low volume across a small number of products, the manual approach can work. For anyone managing more than a handful of departure dates and multiple products simultaneously, double-managing inventory is a reliability risk that grows proportionally with your booking volume.
This guide walks through the Tours Hub API and webhook architecture, the practical integration patterns, and the decisions operators need to make about how connectivity should work in their specific setup.
The Core Integration Problem: Two Inventory Sources
When you run your own booking system and separately connect to a reseller distribution platform, you have two systems that both claim to know how many seats are available on a given tour departure. The fundamental integration goal is to make these two systems agree, in real time, about availability — so that bookings made through the platform decrement your internal system's count, and internal changes to capacity are reflected in what the platform shows resellers.
Without this sync, the failure mode is predictable: a reseller confirms a booking through Tours Hub, your internal system still shows those seats as available, and a direct booking comes in for the same seats. Now you're manually cancelling one of them, damaging a relationship, and providing refunds you'd rather not be processing.
The integration architecture has two primary directions: push (your system proactively sends availability updates to Tours Hub) and pull (Tours Hub reads current availability from your system when it needs it). Pull via API is the most reliable for real-time accuracy; push via webhooks works well for event-driven updates like when you manually close a departure or adjust capacity.
The Availability Sync API
Tours Hub's availability endpoint allows your booking system to push current seat counts for any tour-date combination. A basic availability update looks like this in practice:
POST /v1/tours/{tour_id}/availability
Authorization: Bearer {your_api_key}
Content-Type: application/json
{
"date": "2026-07-15",
"departure_time": "09:00",
"available_seats": 8,
"status": "open"
}The platform processes this and updates what resellers see for that departure. The critical requirement is that your system sends this update whenever its own seat count changes — not on a delayed batch schedule. If your internal system updates availability every 15 minutes, you have a 15-minute window where the platform's count can drift from reality. For low-volume days, this is an acceptable risk. For high-season peak departures where seats are moving quickly, 15 minutes is enough lag to produce overbooking.
Operators running booking systems with real-time internal updates should configure their system to fire an availability push to Tours Hub on every booking and every cancellation, not on a timer. Most booking system platforms that have webhook or API output functionality can be configured to do this.
Booking Webhooks: Getting Notified When Resellers Book
The reverse direction — Tours Hub notifying your system when a reseller books through the platform — uses webhook events. You register a webhook endpoint in your Tours Hub operator dashboard, and the platform sends a POST request to that endpoint whenever a booking event occurs.
A booking confirmation webhook payload contains the fields your system needs to record the booking: the tour ID, departure date and time, reseller ID, pax count, lead traveler name, contact details, and the agreed net rate for that booking. Your system receives this and can automatically create the corresponding booking record in your internal system, decrement the seat count, and trigger your own confirmation workflow.
The standard booking events you'll want to handle are: booking.created (new confirmed booking from a reseller), booking.amended (pax count or date changed), and booking.cancelled (booking cancelled, seats should be returned to inventory). Handling all three keeps your internal system current with the full lifecycle of reseller bookings.
Handling the Partial Integration Scenario
Not every operator has a booking system with API output capability. Many smaller operators run on purpose-built tour management software or even Google Sheets-based systems that can't fire webhooks. For these operators, the integration path is manual availability management with maximum discipline, or migration to a system with connectivity.
We're not saying that every operator needs full API integration before they can use Tours Hub effectively. Many operators manage availability reasonably well through the platform's web interface, manually updating seat counts as bookings arrive. The limitation is that this requires consistent attention — updates need to happen promptly across both systems — and it creates a dependency on a specific person's diligence that introduces risk during busy periods, illness, or staffing gaps.
The practical recommendation for operators in this position is to define a clear availability management protocol: which system is the authoritative source, how quickly platform counts get updated when the authoritative source changes, and who is responsible for that update. Manual management with clear protocol is significantly more reliable than manual management with no defined owner.
Rate and Product Data Sync
Beyond availability, operators who want to avoid manually maintaining product details and pricing in two places can use the Tours Hub product API to push rate and product updates from their internal catalog. The products endpoint allows creating and updating tour products, pricing tiers, and product metadata via API, so that a product update in your internal system propagates to the platform without a separate manual entry.
For operators with a small number of products, this sync matters less — updating five products manually in two places is not a meaningful burden. For operators managing 20+ products with seasonal rate changes across multiple pax tiers, maintaining two product catalogs manually introduces enough error risk that API-based catalog sync becomes worth the setup time.
Testing Before Going Live
The Tours Hub API sandbox environment mirrors the production API with test tour IDs and test reseller accounts. Any integration should be built and validated against the sandbox before pointing at production inventory.
The specific scenarios worth testing before going live are: a reseller booking that correctly decrements your internal system's count, a cancellation that correctly returns inventory, an availability update from your system that correctly updates what the platform shows, and a deliberate conflict scenario where you try to overbook past available capacity to verify that the system blocks it correctly. Running through these scenarios in sandbox — not just testing that the API call returns a 200 — is the difference between an integration you trust and one you're nervous about the first time it runs in a real booking situation.
