Hospitable booking widget integration

Designed for exactly this

Hospitable publishes a booking widget so hosts can add booking to an existing site rather than building a standalone one¹². It is an explicitly supported route, which removes the usual uncertainty about whether a custom front end is allowed.

In practice that makes Hospitable one of the more comfortable platforms to design around. The automation stack — messaging, calendars, locks, cleaning — carries on untouched, and only the guest-facing layer is ours to build.

Designing around the seams

Every embedded component has edges. The widget can be brought close to your brand but not made identical to it, and the payment step behaves as Hospitable designed it.

The work is in the surrounding page. Guests forgive a component that looks slightly different if it appears at the right moment in the right place. What they do not forgive is a visual language that changes mid-journey, or a total price that appears for the first time at the payment step.

• Availability and total price visible before the widget is reached
• Type scale and spacing matched to the component rather than fighting it
• Widget placed at the decision point, not below three sections of copy
• Consistent visual language maintained through the transition

Where it fits in a bigger build

For most Hospitable operators the widget is the whole integration, and the project is a design and content project rather than a technical one. That is usually good news for cost and timeline.

Above roughly twenty properties, portfolio search starts to matter more than the widget itself, and the build shifts towards search architecture with the widget handling only the final steps.