Microsoft Bookings on your website: every embed option

Microsoft gives you two ways to put a shared booking page on a website: a link, and an iframe copied from the Booking page section in Bookings. Everything else, from a styled widget to a fully custom form, is built by a third party on top of the public page or on Microsoft Graph. Each method trades effort against what you lose: the iframe keeps visitors on your page, but you can't size it to its content, style it or see a booking happen inside it.

"Bookings with me" pages (Microsoft now calls them Personal Bookings) have no embed option at all. This chapter covers what each method costs you, as of October 2026. Tracking is covered separately in Conversion tracking.

The methods compared#

What Microsoft supports and what it doesn't#

The Bookings FAQ answers "Can I use Bookings in my own Web site?" with an iframe, and says the embedding code is "located in the Bookings page tab" (the UI calls it Booking page). The sharing article lists four options for a shared page: Copy Link, Share on Social Media, Share via Email and Embed in Your Website, which copies "the link and the iframe in just one click". That is the whole of the documented embed.

Where the settings live, and the custom domain article in detail, are in Customize and publish the booking page.

Linking out#

A link is the most robust method, and on phones it's often the best one, because the booking page gets the whole screen. Use a button that opens in a new tab so your page is still there after the booking. The costs are on the Microsoft side of the link. The address shows the booking mailbox (for example /book/Sales@contoso.com/). The page Microsoft serves is titled "Bookings" and carries noindex, so it can't stand in for a page of your own in search (page title and previews). And your analytics stops at the click.

The FAQ still describes a link per service under Service booking page. A Microsoft Q&A moderator said in April 2026 that per-service links are no longer offered and suggested a separate booking page per service instead, so check your tenant before you plan around them. There's no parameter that picks a staff member or fills in the form. For printed material, a QR code of the plain link plus a RefID works (QR code).

The plain iframe#

The iframe keeps visitors on your page, but it's still the page Microsoft hosts on a Microsoft domain. These are the problems that come up most:

• "Refused to connect" or a blank box. Usually Require a Microsoft 365 account from my organization to book is on, or a tenant setting forces sign-in. The frame then loads the Microsoft sign-in page, which sends headers that refuse framing. Old /owa/calendar/ URLs, extra query strings and your own Content-Security-Policy cause the rest. If your site sends a frame-src rule, allow every Microsoft host the browser console names, including bookings.cloud.microsoft where current links redirect. The symptom table is in refused to connect.
• Height. height='100%' collapses in most layouts. The frame can't report its height, so you pick a fixed pixel height tall enough for the longest step, and a taller one for phones (height and mobile).
• Mobile layout inside the frame. Users have traced cut-off time pickers to fixed widths in the Bookings stylesheet. Only Microsoft can fix those. A button on small screens is the usual fallback.
• Styling. Your CSS can't reach inside a cross-origin frame (custom CSS). Branding comes from the logo, the colour theme and what you put around the frame (branding guide).
• Measurement. Your tags can't see the steps or the confirmation, and there's no redirect (Conversion tracking).

SharePoint, WordPress and site builders#

The host adds its own rules on top of the iframe limits:

Steps per host are in SharePoint, WordPress and site builders. In React, Next.js, Vue, Svelte or Astro the iframe is just a component, and the framework guide explains why its load event isn't a booking.

Bookings with me pages#

The Personal Bookings FAQ says "Bookings with me and Personal Bookings are terms used interchangeably", and the sharing article for personal pages lists three options: copy link, share via email and email signature. There's no embed code. Framing the link anyway is unsupported: bookers may see a sign-in or guest step and an email code you can't switch off, and the link format isn't documented. If you need a booking form on your site, the dependable route is a shared booking page with yourself as the only staff member. The trade-offs are in embedding Bookings with me.

Front ends in front of the public page#

Anything that looks better than the iframe or measures more is a third-party layer of one of these types:

• Hand-off widgets show availability on your site, then send the visitor to the booking page to finish. Your tags see the click, not the booking.
• Graph-based forms draw the whole form on your site and create the appointment through Microsoft Graph. They need an Entra app registration and tenant-wide admin consent, they must enforce the Bookings rules themselves, and Graph doesn't cover personal pages (Graph API chapter).
• Front ends on the public page API use the same anonymous calls as the booking page Microsoft hosts. They need no consent but rely on an undocumented API that can change with any Microsoft release.
• Tracking layers leave the iframe in place and add measurement around it.

The approaches compared page sets them side by side, and the custom booking page guide is the developer build.

What we saw when testing (September 2026)#

We captured the public shared booking page and the calls it makes, and made and cancelled a few test bookings. What matters for any custom front end:

• The public booking API sends no CORS headers, so code on your website can't call it from the browser. A server has to sit in between.
• Reads took roughly 0.3 to 1.3 seconds from our server, but creating a booking took about 5.5 seconds. The form needs a clear "booking…" state.
• Called directly, the server accepted a booking in the past and one over a busy Outlook block. The page Microsoft hosts prevents both in the browser, so a custom front end must re-check the slot before it books.
• On pages that require it, Microsoft emails a 6-digit code when the customer first submits, and the booking exists only once the code is sent back.

Doing this with BookingsXP#

BookingsXP is a front end of the public-page type: you paste your public booking page link and get a script widget, inline, as a popup or as a floating button, that resizes to its content and pushes each booking step to your page's dataLayer. There are eight templates, a WordPress plugin, snippets for the common site builders, and a hosted page at bookingsxp.com/book/<name> (on our domain, not yours) for places that only take a link. It needs no Microsoft sign-in or admin consent, appointments are still created in Microsoft Bookings, and Bookings with me pages are supported on a best-effort basis only. See the embed feature. BookingsXP is independent and not affiliated with or endorsed by Microsoft.