We build and maintain Bokun integrations in production — inventory-service plugins, product and rate sync, availability feeds, and booking flows — and we host and monitor what we build.
Bokun (Bókun) is the booking and channel-management platform for tours, activities, and attractions, part of the Tripadvisor group. Operators use it to hold their products, rates, and availability in one place, sell directly through its booking engine, and distribute the same inventory out to OTAs and to its B2B marketplace.
The Bokun API is how you connect your own systems to that: read and write products, pull availability, create and cancel bookings, and — if you are the one holding the inventory — serve availability and pricing back to Bokun as a channel manager. It is a capable API with a lot of surface area. Most of the cost in a Bokun project is not writing the first request — it is the mapping, the edge cases, and making sure the thing keeps working once nobody is watching it.
Reading the documentation is the easy half. These are the areas that decide whether an integration takes weeks or months — and the ones we scope carefully before quoting.
There are two ways to be on the other side of Bokun. If Bokun is the system of record, you read from it and write to it over REST. If your system holds the inventory, you implement an inventory service — a channel-manager plugin that Bokun calls for availability and pricing, and notifies when a booking is made or cancelled.
The second is where the real engineering is. Bokun calls your endpoint on its own schedule and expects fast, correct answers; the mapping between its rate structure and yours has to be exact; and the booking lifecycle has to stay consistent on both sides. We have built and operated this layer in production, which is a different thing from having read the specification.
API access comes with a Bokun account rather than as a separate product. You generate an access key and secret in the account settings, and each request is signed. What you can reach depends on the permissions of the account the keys belong to — vendor, reseller, and marketplace roles see different things, which is a common source of confusing 403s and empty results early in a project.
Yes, in two different ways. You can write products, rates, and pricing over the REST API so Bokun holds the data. Or, if your own system is the source of truth, you implement an inventory service and Bokun asks you for availability and pricing in real time. The first suits a catalogue that changes occasionally; the second is what you need when availability is live.
The API is the interface you call. The channel manager is the distribution function — one set of inventory, many sales channels, without overselling. You can use the API without touching distribution, and you can distribute through Bokun without writing code. Connecting your own inventory as a channel is where the two meet, and that is an inventory-service plugin.
A read-only sync — pull products, availability, and bookings into your own system — is usually a short piece of work. A full inventory-service plugin with pricing, booking creation, and two-way cancellation is a longer build, and the time goes into mapping and edge cases rather than the happy path. We will give you a scoped estimate once we have seen the account and what it has to talk to.
Yes, and most real integrations need both. The two generations cover different ground, and a given field is often readable from one and writable only from the other. Knowing which is which up front saves a great deal of time.
Yes. A lot of what we are asked to do is repair: mappings that no longer line up, cancellations that do not propagate, reports that do not reconcile, a plugin that goes quiet with no health check in front of it. We will tell you honestly whether it is cheaper to fix or to rebuild.
We are usually working in several of these at once, which is how we know where each one bites. See all integrations for the full list.
Attraction and tour ticketing on the OCTO spec — availability, holds, settlement methods, and reseller billing.
View detailsXML API for tour operators and agents — tour search, availability checks, and channel-level booking.
View detailsThe integration layer itself: one inventory source distributed to many OTAs without overselling.
View details