Which Graph permissions does Microsoft Bookings need?

What each permission allows#

From the Graph permissions reference:

• Bookings.Read.All: read appointments, businesses, customers, services and staff.
• BookingsAppointment.ReadWrite.All: read and write appointments and customers, and read businesses, services and staff.
• Bookings.ReadWrite.All: read and write all of the above, but "does not allow create, delete and publish of booking businesses".
• Bookings.Manage.All: full management, including creating and publishing booking businesses.

The application versions all need admin consent. The delegated versions are marked as not needing it, so unless your Microsoft Entra ID consent settings block it, a user could consent to one for an app.

Least privileged permission per task#

Two notes from the method pages. Apps that create or update appointments with application permissions "must follow the business rules" (hours, duration, lead time, staff selection); the business rules page says this is "to prevent unforeseen errors". And a public-facing availability lookup has to use application permissions, because getStaffAvailability has no delegated version. The Graph API only covers shared booking pages, not "Bookings with me". For turning availability into bookable times, see the available time slots API.

Can I limit access to one booking page?#

Not with a documented setting, as of September 2026.

• Application permissions reach every booking mailbox in the tenant. The 2025 Microsoft Q&A answer agrees: the scopes "are designed to work at the tenant level", with no "own bookings only" option.
• RBAC for Applications in Exchange Online is how Microsoft lets admins scope an app to certain mailboxes. Its list of supported application roles (page updated August 2026) covers mail, mailbox settings, calendars, contacts and mailbox folders and items. It has no Bookings permissions. Microsoft doesn't document using it, or the older application access policies, for Bookings.
• Delegated permissions: Microsoft says an app acting for a user is limited by "the Microsoft Graph permissions that the app has been granted and the user's own permissions". It doesn't spell out what a user's own permissions mean in Bookings, such as only pages where they have a staff role. The community answer on Q&A treats delegated access as tenant-wide. Test with a non-admin account before you rely on it.

What you can do:

1. Grant the least privileged permission from the table, not Bookings.Manage.All by default.
2. Control consent in Microsoft Entra ID: block user consent for these permissions, or allow it only for a named group through an app consent policy. The person asking in the 2025 thread confirmed this solved the question of who can consent.
3. Filter in your own app. Hard-code or configure the booking business IDs it may touch, and refuse the rest.
4. Monitor sign-ins and Graph activity for the app, and use Conditional Access where it fits.

For admins who just need to see every calendar, admin access to all Bookings calendars covers mailbox permissions and the export.

The 403 when updating a booking business#

In the 2024 Q&A thread, a PATCH to a booking business returned 403 Forbidden even though the change was applied. The token had Bookings.Manage.All, and the business had been created with delegated permissions. A later reply said it reproduced the 403 with only Bookings.Manage.All as an application permission and fixed it by adding three more permissions, but the list didn't survive in the thread. Microsoft documents Bookings.ReadWrite.All as least privileged for this call. If you hit it:

• Decode the token and check whether it's delegated (scp) or application (roles), and that the permission you expect is there.
• Add Bookings.ReadWrite.All alongside Bookings.Manage.All and retry.
• Send only the properties you're changing in the PATCH body.
• Re-read the business afterwards to confirm the change, because a 403 here didn't mean nothing happened.

Doing this with BookingsXP#

The BookingsXP booking widget needs no Graph permissions, app registration or admin consent. You paste your public booking page link, and it reads only what that page shows to any visitor: services, staff names and open times. Bookings are then created the same way the public page creates them. The trade-off is that it can do only what the public page can: it can't read other booking pages, your customer list or staff calendars. BookingsXP is independent and not affiliated with or endorsed by Microsoft.