Holibob's SDK Elements

The fork that isn't there

Most integration decisions come with a fork in the road. You can take the widget and ship quickly, then hit a ceiling. Or you can build against the API properly, which takes months but gives you full control. Pick the quick route and you usually end up rebuilding later.

We built the SDK so that choice doesn't exist. Every element (search, the product page, availability, checkout) calls the same signed operations the API documents. Those calls go through a proxy you serve from your own server, which is also where your API key and secret stay. That holds whether you use every element, one of them, or none at all.

So on the first day you have full API access. The elements are a head start on top of it, and they play by the same rules as anything your team builds.

One integration. The elements and your own code call the same operations through the same proxy.

The elements build the part nobody competes on

Every booking flow has to render results, check availability, collect traveller details and booking questions, and move the booking through its states without losing anything. All of it has to exist before you can sell a single experience, and none of it is where your product differs from a competitor's. The experience economy also has a vast array of different conditional questions: what harness size do you need, do you have any allergies, does the child need a support penguin with the ice skate hire.

That's the part the elements handle. It's why a build that has usually meant months of roadmap now takes around three days of one developer's time, most of it spent reading documentation.

The day you need something the elements don't draw

At some point you'll want a screen we haven't built. It might be a bespoke itinerary view, a native app, or a pricing rule that only applies to your top loyalty tier.

When that day comes, you call the same operations the elements call, through the same proxy, in the integration you already have running. You don't start a second project, and there's no migration because there's nothing to migrate from. The elements you still use carry on working next to the code you've written yourself.

We'd be overselling if we said the elements cover every case. They don't, and they were never meant to. When they run out, your team carries on in the same integration instead of scoping a rebuild.

Most teams end up in the middle

Very few partners take the whole storefront exactly as it ships. The more common pattern is to take individual elements, such as the discovery grid, a product page or the availability picker, and place them inside layouts that already exist. Your navigation and your header stay as they are. The elements sit in your pages, on your domain, with no iframe and no redirect.

For a team with its own booking engine, that's often the answer. Keep the engine for flights, rooms or packages, and let the elements carry a catalogue of 500,000+ experiences it was never designed for.

The proxy belongs to you

The proxy is around two hundred lines of code. You download it once and it's yours to change. We ship a Node version today, and the contract underneath is language-agnostic, so your team can rewrite it in whatever they already run.

This is where your own logic lives: your payment gateway, your loyalty programme, agent wallets, your identity and authorisation checks. Out of the box it refuses booking calls until someone on your side writes that authorisation check. It fails closed rather than open, which is the default you want on the one route that can create a booking.

Nothing of ours to fall behind on

The browser SDK loads from a versioned CDN path. When we fix something, the fix reaches your travellers within minutes and you have nothing to redeploy. When we make a breaking change, it gets a new path, and the old one keeps working until you choose to move.

No Holibob package enters your dependency tree either, in any language. There's no version of ours to pin or fall behind on.

Keep the engine. Hand over the standard parts.

If you already have a booking engine, the SDK doesn't ask you to give it up. It asks you to stop hand-building the standard parts of an experiences flow, and it gives you the whole API underneath for everything else. That gets experiences on sale in the week before travel, when around 70% of activity bookings are made, without adding a quarter to your roadmap.

The quickest way to judge is to build with it. The sandbox runs against our production systems, so your developer gets the full catalogue, real availability and the whole booking flow from day one. The supplier is never contacted and nothing reaches a bank. When a commercial agreement is in place, we clear the sandbox flag, and the same credentials, proxy and code start taking real bookings. Nothing gets rebuilt for launch.

You can click through the storefront at demo.holibob.tech/solutions/holibob-sdk. For sandbox credentials, book fifteen minutes with us at holibob.tech/holibob-sdk, where you'll also find the FAQ.