Channel manager for tours, activities & rentals · OCTO conformant

Sell every seat once.
On every channel.

One inventory for every sales channel. Tako keeps availability and bookings consistent between your booking system, OCTO resellers and OTAs like Viator, through one API. No overbookings, no spreadsheets.

Book a demo Read the docs

app.takoconnect.com/availability

Availability

Blue Coast Charters · week 25

● 3 channels in sync

Option	Mon 15	Tue 16	Wed 17	Thu 18	Fri 19	Sat 20	Sun 21
Sunset cruise · 18:30	9/12	12/12	4/12	0/12	7/12	3/12 01Viator · booking received4 → 3	11/12
Snorkeling tour · 09:00	8/8	6/8	8/8	2/8	8/8	1/8	8/8
Boat rental · full day	3/3	1/3	3/3	3/3	0/3	2/3	3/3

Reconciliation ran 02:00 · 0 drifts across 3 channels

Built on open standards, not on one marketplace

OCTO
Core · pricing · notifications, conformance-tested
OpenAPI 3
Full REST contract, generate any client
llms.txt
The same contract, written for agents
Viator
Supplier API connector, live
PostgreSQL
Transactional inventory, never cached

The problem

Two calendars, one seat, two happy customers. Until Saturday.

Availability lives in a dozen tools, belongs to a dozen marketplaces, and drifts the moment one of them sells a seat. The overbooking is discovered at the dock.

Without a shared inventory

Viator · own calendar

Sunset cruise · Sat 20

1/12 left

✓ Sold 18:31

Your website · own calendar

Sunset cruise · Sat 20

1/12 left

✓ Sold 18:31

2 bookings, 1 seat. You find out from the customer.

With Tako

Inventory · Boat “Aria” · Sat 20

Sunset cruise · 18:30

1/12 · locked

Viator · 18:31:02

✓ Confirmed

Your website · 18:31:02

0/12 · availability pushed

One transaction decides. Every channel is told within seconds.

How it works

Bookings in, availability out, in seconds

Capacity is modelled on the resource that delivers the experience, so one boat can back three products without conflicts. From there, every booking follows the same three steps.

Read about the domain model →

01
A booking lands, from any channel
Viator webhook, OCTO reseller, your own portal or an AI agent: every path maps into the same booking command. No parallel logic per channel.
- Viatorwebhook · signature verified
- OCTO resellerPOST /api/octo/bookings
- Your portalPOST /api/v1/bookings
- AI agentsame endpoint · idempotency key
- ↓ one CreateBookingCommand
02
One transaction decides
Inventory is locked on the resource that delivers the experience, capacity and unit items are validated, the booking and its outbox event are committed together.
1. LOCK inventory→
2. VALIDATE capacity→
3. WRITE booking→
4. OUTBOX event→
5. COMMIT
6. one transaction
03
Every channel is told, and checked
The change fans out through the queue with retries and backoff. A scheduled reconciliation pass repairs whatever a lost webhook or a provider outage missed.
- Viator · availability pushretry 2/5 · 429
- OCTO · PMS · booking confirmsynced · 0.9s
- Viator · credentialsneeds action
- Reconciliation · 02:000 drifts · 3 channels

Under the hood

Two transport surfaces, one domain. Consumers call REST or OCTO; providers plug in as connectors; nothing in between knows which marketplace a seat came from.

Consumers

Portal
PMS · booking system
AI agent
Reseller

Tako

Catalog · Resources
supplier → product → option → unit
Inventory
authoritative capacity per resource
Availability
computed and published per channel
Booking engine
one transactional path for every channel
Sync
outbox · retries · reconciliation

Connectors

Viator · Live
OCTO providers · Live
More marketplaces · Roadmap

Proven, not promised

Three guarantees, each one a test in CI

Transactions, idempotency and reconciliation are table stakes. What sets Tako apart is that every one of them fails the build if it stops being true.

1 / 100

bookings accepted

on the last seat, under 100 concurrent requests

Inventory is locked inside a PostgreSQL transaction. CI fires 100 parallel bookings at one seat: exactly one confirms, capacity never reaches −1.

✓ CI · booking.service.spec.ts

1 booking

per event

however many times the event is delivered

Every external operation carries a deterministic idempotency key. Duplicate webhooks and client retries return the same booking, not a second one.

✓ CI · idempotency contract suite

0 silent

failures

every failed sync is a visible job, not a lost one

Each sync is a traceable job with attempts, correlation id and failure class. Transient errors retry with backoff; credential or mapping errors are surfaced to you.

✓ CI · sync tracking suite

Integrations

Viator, OCTO resellers and providers, your own booking system

Adding a channel never touches your inventory. One connector is shipped production-grade at a time; the roadmap is ordered by who asks first.

Discover all integrations →

Live

Viator

Live

Inbound bookings, cancellations and availability, with reconciliation.

OCTO resellers

Live

Any OCTO-compatible reseller reads your catalog and books.

OCTO providers

Live

Push your catalog outbound to OCTO-speaking platforms.

Your PMS

Live

Your own portal or booking system through the REST API and SDK.

AI agents

Live

Quote, book and reconcile through idempotent endpoints.

Roadmap

GetYourGuide

Roadmap

Next connector, production-grade first.

Rezdy

Roadmap

Tell us if you need this one first.

Bokun

Roadmap

Tell us if you need this one first.

Developers

One idempotent request, from any surface

From quote to confirmation, the same booking engine. Create on hold, confirm, and let Tako propagate the change everywhere. Retries are safe: the same idempotency key returns the same booking, whether a PMS or an agent sends it.

Explore the API →

RESTSDKOCTOAgent

RequestPOST /api/v1/bookings
Authorization: Bearer cm_live_…
Idempotency-Key: pms:supplier-42:order-123

{
  "optionId": "opt_sunset_cruise",
  "startAt": "2026-06-15T18:30:00Z",
  "unitItems": [
    { "unitId": "unit_adult", "quantity": 2 },
    { "unitId": "unit_child", "quantity": 1 }
  ],
  "customer": { "firstName": "Ada", "lastName": "Rossi" },
  "status": "ON_HOLD"
}

Response201 Created
{
  "id": "bk_9f2c",
  "status": "ON_HOLD",
  "expiresAt": "2026-06-15T18:00:00Z",
  "unitItems": [ … ]
}

Then, asynchronously

Booking received
→ Viator
synced · 0.2s
availability.changed
→ OCTO · Portal
synced · 0.4s
availability.changed
→ Viator
retrying · 2/5
availability.changed
→ OCTO · PMS
synced · 0.9s

Requestimport { Tako } from "@tako/sdk";

const tako = new Tako({ apiKey: process.env.TAKO_KEY });

const booking = await tako.bookings.create(
  {
    optionId: "opt_sunset_cruise",
    startAt: "2026-06-15T18:30:00Z",
    unitItems: [
      { unitId: "unit_adult", quantity: 2 },
      { unitId: "unit_child", quantity: 1 },
    ],
    status: "ON_HOLD",
  },
  { idempotencyKey: "pms:supplier-42:order-123" },
);

Responsebooking.id      // "bk_9f2c"
booking.status  // "ON_HOLD"

// same key, same booking — safe to retry
await tako.bookings.confirm(booking.id);

Then, asynchronously

Booking received
→ Viator
synced · 0.2s
availability.changed
→ OCTO · Portal
synced · 0.4s
availability.changed
→ Viator
retrying · 2/5
availability.changed
→ OCTO · PMS
synced · 0.9s

RequestPOST /api/octo/bookings
Authorization: Bearer cm_live_…
Octo-Capabilities: octo/pricing

{
  "uuid": "6f4a…-reseller-generated",
  "productId": "prod_sunset",
  "optionId": "opt_sunset_cruise",
  "availabilityId": "2026-06-15T18:30:00+02:00",
  "unitItems": [
    { "unitId": "unit_adult" },
    { "unitId": "unit_adult" },
    { "unitId": "unit_child" }
  ]
}

Response200 OK
{
  "uuid": "6f4a…",
  "status": "ON_HOLD",
  "utcExpiresAt": "2026-06-15T16:00:00Z",
  "pricing": { "currency": "EUR", "total": 13500 }
}

Then, asynchronously

Booking received
→ Viator
synced · 0.2s
availability.changed
→ OCTO · Portal
synced · 0.4s
availability.changed
→ Viator
retrying · 2/5
availability.changed
→ OCTO · PMS
synced · 0.9s

Run trace# assistant run · "book the sunset cruise for 2 adults, 1 child on the 15th"

→ tool  getAvailability(optionId="opt_sunset_cruise", date="2026-06-15")
← 18:30 · 3 seats available · EUR 45.00 / adult

→ tool  createBooking(..., status="ON_HOLD",
        idempotencyKey="agent:run-7c1:booking")
← bk_9f2c · ON_HOLD · expires 18:00

→ tool  createBooking(...)          # network timeout, retried
        idempotencyKey="agent:run-7c1:booking"
← bk_9f2c · ON_HOLD                 # same key, same booking

→ tool  confirmBooking("bk_9f2c")
← bk_9f2c · CONFIRMED

Context# what the agent read first
GET docs.takoconnect.com/llms.txt
GET docs.takoconnect.com/openapi.json

# what it never had to know
- which OTA the seat came from
- how capacity is locked
- that the retry was a duplicate

Then, asynchronously

Booking received
→ Viator
synced · 0.2s
availability.changed
→ OCTO · Portal
synced · 0.4s
availability.changed
→ Viator
retrying · 2/5
availability.changed
→ OCTO · PMS
synced · 0.9s

API reference ↗

Every endpoint, request and response, with examples.

OpenAPI contract ↗

Generate clients or feed it to your agent.

Official SDK ↗

Typed client for Node and browsers.

llms.txt ↗

The contract, written for AI assistants.

Who it is for

Built for operators and platforms where a double booking is not an option

Run your own inventory, or other people's, from one deployment. Every entity is tenant-owned and every API key is scoped.

Tour & activity operators

Stop closing sales on one channel to protect another. Every marketplace sees the same calendar, and you hear about a booking from Tako, not from the customer.

Inventory that never goes negative: capacity is locked and validated inside PostgreSQL, never trusted from a cache.
Sync you can trace: every push is a job with attempts and a failure class. Retry it from the dashboard, through the same queue.

Booking systems & PMS

Add OTA and OCTO distribution to your product through one REST API and one SDK, instead of one integration per marketplace. Headless, white-label ready.

One booking engine for every path: OCTO, portal and connector bookings share the same transaction.
Multi-tenant from day one: tenant-owned entities and scoped API keys, so you can run other people's inventory.

Resellers & OTAs

Read catalog, availability and pricing and place bookings over the OCTO standard, no custom work.

OCTO Core, pricing and notifications validated with the conformance suite on every build.
Bookings carry explicit unit items, 2×Adult and 1×Child, not a bare quantity.

AI agents

A machine-readable contract and idempotent endpoints let assistants quote, book and reconcile safely.

Idempotency built in: the same key returns the same booking, so an agent can retry without fear.
OpenAPI and llms.txt describe every endpoint, request and response for tools and assistants.

FAQ

Questions operators ask us

What is a channel manager for tours and activities?

A channel manager keeps the availability, prices and bookings of your experiences in sync across every sales channel: OTAs like Viator, resellers, your own website and your booking software. Tako does this through one API and one shared inventory, so you never sell the same seat twice.

What does “agnostic” mean for Tako?

Tako is not built around one marketplace, one booking system or one vertical. Providers are plugged in as connectors, consumers talk to a proprietary REST API or to the OCTO standard, and the domain model in the middle stays neutral. Boats, tours, rentals and experiences are all first-class.

Is Tako OCTO compatible?

Yes. Tako exposes an OCTO Core API with pricing and notification capabilities, validated with the OCTO conformance suite. Internally the domain is not coupled to OCTO, so the standard can evolve without breaking your integration.

How does Tako prevent overbookings?

Every booking, from any channel, runs through the same transactional engine: inventory is locked, capacity and resources are validated, then the booking is written and an outbox event is committed atomically. Cached or client-side availability is never trusted for confirmation.

Which channels are supported?

Viator is available today as an inbound connector, and any OCTO-compatible reseller or platform can connect through the OCTO API. Additional marketplaces are on the roadmap; one connector is shipped production-grade at a time.

Can I use Tako without the dashboard?

Yes. Tako is headless and API-first. The dashboard is optional; booking systems, PMS and portals integrate directly through the REST API or the SDK.

Turn one calendar into every channel

A 30-minute walkthrough with the engineer who built the booking engine, not a sales deck.

Book a demo Explore the API

In those 30 minutes
Map one of your products onto resources, options and units
Connect Viator or an OCTO reseller to it
Watch a booking land and the availability change fan out

Sell every seat once.On every channel.

Two calendars, one seat, two happy customers. Until Saturday.

Bookings in, availability out, in seconds

A booking lands, from any channel

One transaction decides

Every channel is told, and checked

Three guarantees, each one a test in CI

Viator, OCTO resellers and providers, your own booking system

One idempotent request, from any surface

Built for operators and platforms where a double booking is not an option

Tour & activity operators

Booking systems & PMS

Resellers & OTAs

AI agents

Questions operators ask us

Turn one calendar into every channel

Sell every seat once.
On every channel.