Overview

The Service widget is a booking form that checks live availability and creates the reservation directly in the restaurant’s calendar. It runs in the guest’s browser — either on a ready-made page we host, or embedded in your own site.

It needs no API key and no backend work. Availability and booking are public operations against one restaurant, so there is no credential to put on a page.

There are two ways to use it, and the first involves no code at all.

The simplest way: the booking page

Every restaurant already has one, live now, with nothing to build:

https://book.useservice.app/r/chez-marie

Link to it from your navigation, an e-mail, a QR code on the table, or a Google listing. No script, no deploy, nothing to maintain, and it is always on the current version. For many restaurants this is the whole integration — see The booking page.

The rest of this page is about putting the same form on your own page instead, so the guest never leaves your site.

Putting it on your own page

Load the booking widget on your site in one of two ways:

A script tag. One line of HTML, no JavaScript to write. This is what the back office hands you and what almost every integration uses.
The JavaScript API. You call ServiceWidget.create() yourself, which gives you a handle to open and close it, pass it context, and listen for events. Reach for it when your page needs to drive the widget rather than just display it.

Either way, data-mode (or mode) decides how it appears, and for most integrations that is the only decision to make. Both are covered in Booking widget.

Inline

Renders in the flow of the page, inside a container you place. Use it for a dedicated “Book a table” page or a section of the homepage: the form is visible without the guest clicking anything.

<div id="service-widget"></div>
<script src="…/widget.js" data-slug="chez-marie" data-mode="inline" async></script>

Renders nothing until something opens it. You supply the button, so it can sit in your own navigation and match your own design. Use it when booking is one action among several rather than the point of the page.

<button data-service-widget-open>Book a table</button>
<script src="…/widget.js" data-slug="chez-marie" data-mode="popover" async></script>

Sticky

The widget renders its own floating button, anchored to a corner, and opens itself. Nothing on your page needs to change — useful when you cannot edit the template, only add a script.

<script
  src="…/widget.js"
  data-slug="chez-marie"
  data-mode="sticky"
  data-position="bottom-right"
  async
></script>

On mobile, all three present as a full-screen sheet regardless of which you chose. The mode decides how the guest reaches the form, not what the form looks like once open.

Making it yours

Colour, language and what the form asks for are set by the restaurant, in its Service back office — not in your markup. That is deliberate: the restaurant changes its own branding without editing your page, and a redesign on your side cannot break its booking rules. See Appearance for the boundary.

Going further

Everything below is optional, and most integrations use none of it. Reach for it when the widget needs to know something your page already knows.

If you want to	See
Open the form already showing a date, party size or service	Passing context
Skip the contact form for a guest you have already signed in	Identifying the guest
Show some of those values as fixed rather than editable	Locking fields
React in your own code when a booking is made	Events
Carry the same context through a link instead of a script	Deep links
Compare the approaches before committing	Choosing an integration

Relationship to the API

The widget and the API are separate products, and most integrations that use both use them for different halves of the job.

	Widget	API
Runs in	The guest’s browser	Your server
Authentication	None	`sk_live_…` API key
Operations	Creates bookings	Reads bookings and guests

The widget takes the booking; the API and its webhooks tell your other systems about it.