Three days, not six months.
The Holibob SDK launched in Q3 2026: a full-fidelity experiences storefront with search, product, availability and checkout across 500,000+ products in 190 countries, which a partner’s developer can have running in their own infrastructure in three days, not six months.
curl -O https://sdk.holibob.tech/v1/shells/node-proxy-starter.zipunzip node-proxy-starter.zip -d my-storefrontcd my-storefrontnpm install && npm start
Seconds later, what is running is a full-fidelity multilingual, multi-currency storefront: search, results, display and checkout, on a developer’s machine, the same day they started.
The most expensive line item in any experiences integration has never been the commercial terms. It’s the engineering queue.
Sourcing global supply, building search and a product page, wiring availability and checkout when every supplier has different data and requires different inputs, handling payment across many currencies. A native integration into a things-to-do catalogue will reliably cost a partner two to three quarters of a tech roadmap. Six months is the number we hear most often, and it is usually right, for a from-scratch build against a new API, done once and then maintained forever.
That number is now wrong. In Q3 2026 we launched the Holibob SDK, and it is live at holibob.tech. It cuts that six-month build to three days, most of which is your developer reading the docs rather than writing code against them, because we give you the code.
A native integration
6 months ++
A from-scratch build against a new API, done once and maintained forever.
With the Holibob SDK
3 days
Most of it a developer reading the docs rather than writing code against them.
Because we give you the code.
The largest untapped revenue opportunity most brands already have
Every travel brand sitting on a large, engaged customer base has the same unrealised asset: in-destination spend that is already happening, just not through them.
The largest untapped revenue opportunity many brands have access to is the £300bn experiences industry, the fastest-growing segment in travel. The term “experiences” undersells what’s on offer: the same catalogue and the same integration reach live events, restaurants, dining, and more, not just tours and attractions.
Seventy per cent of activity bookings happen within a week of travel, in the gap between a confirmed flight or hotel booking and the trip itself.
The experiences industry, and the fastest-growing segment in travel.
Of activity bookings happen within a week of travel, after the flight or hotel is confirmed.
Bookable products, available to build and demo against before you sign anything.
Countries, aggregated from 45+ API partners and direct contracts.
Where it has historically stalled is the build
Everyone agrees the opportunity is real. A product team prices out a native checkout integration, the estimate comes back at six to eight months of engineering, and the initiative quietly drops off the roadmap in favour of something with a shorter path to shipped.
The category was never short of demand. It lacked a reliable, pre-built, low-risk way to surface it.
The SDK removes the build. It doesn’t just shorten it.
For you, that means no engineering project to scope, no six-month line item on your roadmap, and nothing to budget for before you can see it working. Your developer can have a real, working storefront running in your infrastructure, your app, your website before the next roadmap review, starting from a few lines typed into a terminal.
Your developer’s terminal
curl -O https://sdk.holibob.tech/v1/shells/node-proxy-starter.zipunzip node-proxy-starter.zip -d my-storefrontcd my-storefrontnpm install && npm start
What’s running, seconds later
A full-fidelity multilingual, multi-currency storefront: search, results, display and checkout with over 500,000 products in 190 countries, on your developer’s machine, the same day they started. It behaves exactly like the live product, because it is the live product.
- Multilingual
- Multi-currency
- 500,000+ products
- 190 countries
- From search to checkout
Deliberately small, and deliberately yours
The proxy is code you download once and own forever, and you can quickly adapt it to support your payment gateways, loyalty programs, and agent wallets. The browser SDK itself is served from a versioned CDN path, so a fix Holibob ships reaches your travellers within minutes, with nothing to redeploy on your side.
The elements themselves, holibob-storefront, or the individual discovery, product, availability and booking elements, sit in your pages wherever you choose to place them, styled exactly as the rest of your application or site.
The traveller’s browser
Loads the SDK from one script tag. No Holibob credentials or branding ever appear on that page.
Your server
Runs a small API Proxy configured with a simple B2B credential provided through Holibob.
The traveller’s browser
One script tag. No Holibob credentials or branding on the page.
Your brandYour server
A small API proxy you download once and own. Your payment gateway, loyalty and wallets plug in here.
B2B credentialHolibob
500,000+ products in 190 countries, availability, booking and post-booking.
Production, sandbox flagsdk.holibob.tech/v1, a versioned CDN path: fixes reach travellers in minutes, with nothing to redeploy.Your key and secret never leave your server.You’re not choosing the SDK instead of the API
The SDK is not a simplified alternative to the API that trades power for speed. It is the API: the elements call the same signed operations the Holibob API documents, through the proxy that you serve. You get full API access from day one, whether or not you ever use a single prebuilt element. The SDK just means your starting point is a full-fidelity, pre-certified, and end-to-end implementation from day one. You never have to hand-build the 90% that’s genuinely standard before you can ship.
That’s why it solves what the API solves, only faster. Where your team needs something the elements don’t draw, such as a fully bespoke screen, a native app, or business logic the components were never built to express, you call the same operations directly, in the same already running integration.
Sandbox is the whole product, not a trial
The credential your developer starts with is configured for sandbox mode against Holibob’s production systems. It means the entire catalogue, the entire booking flow, full checkout and email flows are there on day one. The only difference is that bookings aren’t sent to suppliers, and finance reporting, while available, never gets settled.
Catalogue
The entire 500k product inventory is available immediately; this is production.
Payment
Cards mimic success, failure, challenge, and more, but nothing is ever forwarded to a bank.
Post booking
The same emails and vouchers are issued, cancellations and amendments are supported, and notifications are raised.
The supplier
The downstream supplier is never contacted. The booking looks real in every other way.
It searches the real catalogue, prices real availability and takes real test bookings end to end: the full catalogue of 500,000+ live bookable products, spanning tours and attractions, live events, restaurants and dining and more, aggregated from 45+ API partners and direct contracts, available to build and demo against before you sign anything.
Safe by default, not just fast
Speed without a safeguard is how a pilot turns into an accidental invoice.
That matters to you, not just to engineering: it means your developer can build, test and demo the entire storefront with zero risk of a real booking, a real charge or a real customer commitment happening by accident. Nothing commits real money until you decide it should, which means anyone on your team can pick this up and deliver a fully working proof that every part of your organisation can review.
Layer one
Sandbox mode
The first layer of protection, ensuring that no matter how many test bookings are made, nothing will ever be invoiced.
Layer two
Gates in the SDK
Ships in the SDK, in your developer’s hands from day one: simple “gates” where you insert any further security protections your compliance requires, to validate users and to protect against cyber and fraud.
The gate on the experiences category has moved
Access to the experiences category was previously gated by engineering capacity, which meant it was gated by decision seniority: only initiatives that could justify two to three quarters of roadmap and ongoing maintenance got built. That gate has moved. Capture the post-booking window first and you keep, and enhance, the customer relationship and the revenue that comes with it.
Higher repeat booking rate among customers who book an in-destination experience, across partners already running Holibob distribution.
Modelled incremental revenue per 1,000,000 marketable consumers.
The post-booking window
None of that requires a new customer. It requires reaching the ones you already have, in the moment they’re already looking for something to do, before a concierge or a competitor’s retargeting pixel gets there first.
A three-day integration means that window is no longer reserved for organisations with extended developer resources and runway. With a developer and an afternoon to spare, you can have a real, bookable, on-brand storefront running before you walk into the commercial conversation.
What partners ask us first
Someone needs to run the small proxy server and, before going live, wire in your own authorisation check. That’s a few hours of one developer’s time, not a project team. Once it’s running, it requires no maintenance. Holibob never pushes changes into your copy of the proxy. Fixes and enhancements to the storefront elements arrive automatically from the CDN that the SDK loads.
See a working storefront before lunch.
The interactive demo, the full documentation and the proxy contract are live. Download and run the shell; on start it will ask once for the sandbox credentials that are free to request. To talk through what a pilot looks like at your scale, book fifteen minutes with the team.