Booking widget or booking API: how to take bookings on your own website

A booking widget is a ready-made booking form from your booking provider that you add to your website with a snippet of code. A booking API lets your developers build the booking experience themselves, calling the provider's system to check availability and create bookings. A widget is quicker to launch and the provider maintains it. An API gives you full control of design and flow, and you take on the build and the upkeep.

There is also a middle route, where your developers build your own pages with the provider's front-end SDK and hand the guest to the provider's booking flow for the booking steps and payment. For venues with a developer, this is often the best fit.

What is a booking widget?

A widget is usually a script or an iframe that loads the provider's booking flow inside your page, or a button that opens it. The provider handles availability, payment, confirmation emails and changes to the booking. You choose colours, logo and some wording within the settings it offers.

For a single site without a developer, a widget is usually the sensible starting point. The trade-offs are that the flow looks and behaves like the provider's product, design control stops at the available settings, and analytics can need extra setup when the flow runs inside an iframe.

What is a booking API?

An API exposes the provider's data and actions to your code: list services, check availability for a date and party size, create or change a booking, look up a customer. Your developers design every screen and call the API behind it. That allows things a widget can't do, such as booking steps inside your own app, availability shown on a menu or event page, or a flow that combines several services in your own design.

With an API you own the code. You maintain it when the API changes, handle edge cases such as a slot being taken between viewing and confirming, and decide how payments are collected securely. Keep server API keys on the server and out of browser code.

What is the middle option between a widget and an API?

The middle option is a front-end SDK: a code package that runs on your website and talks to the provider for you. Your developers build the pages, account areas and sign-in in your own design, and the SDK hands the guest to the provider's booking flow, either embedded in your page or opened for the option they chose. Some SDKs also return services, prices and availability as data, so you can build your own browsing pages from live information. The provider handles the booking steps, payment and confirmation, so checkout stays with the system that processes the booking.

How do Tiquo's website booking options work?

Tiquo covers each of these routes. At the widget end, every Tiquo customer flow (the set of booking steps a guest goes through when they book themselves) has its own hosted page URL and embed code. You can link to the hosted page, embed the flow on your website or share a branded link, and guests see the services connected to that flow. Booking flows can collect a deposit or full payment as part of the booking. The customer portal is the other no-code option: a branded portal hosted by Tiquo where customers can book services against live availability, see their upcoming bookings and update their details.

For account features on a site built without code, the hosted package is a script copied from Settings > Website SDK into your site's head, or added through a Webflow or Framer embed block. It works on Webflow, Framer, WordPress, Wix or plain HTML without a build step, and Tiquo manages its updates. Data attributes in your markup display login forms, customer details, orders, bookings and wallet cards, and the page updates when a customer signs in or out.

For custom builds, the npm package @tiquo/dom-package gives developers passwordless sign-in with a one-time code sent by email, plus the customer's profile, orders and upcoming bookings for account pages. Its createEnquiry() method sends an enquiry from your own form into Tiquo, matching or creating the customer by email. The package can also embed a Tiquo customer flow in your page. Sign-in is shared across the customer portal, customer flows and the package, so a guest who has signed in on your site isn't asked to sign in again when they book.

That is how the middle route works with Tiquo: your developers build the pages and account areas around the booking, and the embedded Tiquo flow runs availability, the booking steps and payment.

For back-end work, the Admin API gives your server access to your organisation's Tiquo data, using API keys created under Settings > API. Its documented endpoints cover customers, companies, orders and bookings, which suits keeping Tiquo in step with a CRM, finance tool or other back-office system. Keep those keys on the server and out of browser code. Guest-facing booking pages belong in the customer flows and website packages.

Booking widget, SDK or API: which should you choose?

Start with a widget or the provider's hosted booking page unless you have a specific reason not to: a design it can't match, a booking flow that spans several services, or an app. Move to an SDK when you want your own pages without owning checkout. Build against an API when bookings are part of a wider product you already maintain.

Online ordering raises the same choice between a provider's hosted pages and your own build, and our guide to taking collection orders through your own restaurant website covers that side. Hotels weighing up a booking engine alongside a PMS and channel manager can start with our explainer on what each of the three does.