Microsoft Bookings Logic App webhook trigger registers successfully but never fires

Question

Microsoft Bookings Logic App webhook trigger registers successfully but never fires

Julian Ruthberg Olsen 0

I have two Azure Logic Apps Consumption workflows using the Microsoft Bookings connector:

When an appointment is Created
When an appointment is Cancelled

Both workflows are deployed with Bicep. The API connection is deployed as a Microsoft.Web/connections resource and then authorized manually with an integration account.

The Bookings API connection shows as Connected.

The integration account has access to the Bookings calendar.

The booking business SMTP address is correct and can be selected from the dropdown in the Logic App designer.

The trigger registration now succeeds.

Current trigger status:

state: Enabled

provisioningState: Registered

status: Succeeded

Trigger history shows successful registration checks, for example:

status: Succeeded

code: OK

fired: False

But when I create or cancel appointments in Microsoft Bookings, no new trigger history entry appears and no workflow run is started.

Earlier, before moving the workflow into Bicep/modules and deploying the API connection through infrastructure code, the same kind of Bookings trigger worked in dev. After redeploying and re-authorizing the connection, the trigger registers successfully, but Bookings does not appear to send any event to the Logic App.

The trigger definition currently looks like this:

{

"type": "ApiConnectionWebhook",

"inputs": {

"host": {

  "connection": {

    "referenceName": "microsoftbookings"

  }

},

"body": {

  "webhook": {

    "notification_url": "@listCallbackUrl()",

    "resource": "Appointments",

    "change_type": [

      "Created"

    ]

  }

},

"path": "/BookingsService/api/V1/bookingBusinesses/@{encodeURIComponent(parameters('BookingSMTPAddress'))}/webhook/AppointmentCreated"
```  }

}

Questions:

1. Is there any known issue with Microsoft Bookings webhook triggers in Logic Apps Consumption when the API connection is deployed through Bicep and authorized afterwards?

2. Is a redeploy after authorization expected or required for the webhook registration to work correctly?

3. Is there any way to verify the actual webhook subscription in Microsoft Bookings/Exchange after the Logic App trigger says Registered?

4. Are there any hidden requirements for the account used by the Bookings connector beyond being connected and having access to the booking page?

I am mainly trying to understand why the trigger registers successfully, but no appointment events are delivered afterwards.

0 kommentarer

2 svar

Svaret ditt

Answer 1

Please note that this is the Norwegian forum (nb-no). I recommend that you post your question in Norwegian so that more members of the community can help you effectively. If you prefer to use English, you are welcome to post a question in the English forum instead. I greatly appreciate your understanding and cooperation.

Hi @Julian Ruthberg Olsen

Based on the details provided, I understand that your Logic App (Consumption) workflows are failing to fire even though the trigger shows a status of “Registered” and you can successfully fetch the SMTP address in the designer.

Here is a breakdown of why this might be happening and a few critical areas to check based on official documentation and structural differences between Logic App models:

Verification of Microsoft Bookings Permissions

According to the official Microsoft Bookings connector documentation, only Bookings administrators can create or successfully run flows using Appointment triggers (Created, Cancelled, Updated).

Please note that Bookings admins are completely distinct from M365 Tenant Admins.
Simply having access to the Bookings calendar or being able to select the booking business in the Logic App designer is not enough. The exact account used to authorize the API connection must be explicitly assigned the Administrator role within that specific Booking Business page.
When transitioning your environment via Bicep and switching to an integration account, it is likely this account was only granted standard staff or scheduler access. As a result, the Logic App frontend assumes the webhook is registered successfully, but the Bookings backend silently drops or refuses to deliver events to it.

Logic App Consumption Syntax & Connection Binding Check

Looking at the JSON snippet you provided, your workflow uses the following syntax:

"host": {
  "connection": {
    "referenceName": "microsoftbookings"  }
}

If you are deploying a Logic App (Consumption) workflow, this connection reference looks problematic. For an ApiConnectionWebhook trigger under the Consumption model, the standard schema typically expects the name property wrapped around the $connections object parameter, resembling this format:

"host": {
  "connection": {
    "name": "@parameters('$connections')['microsoftbookings']['connectionId']"  }
}

The use of referenceName is characteristic of Logic App (Standard) single-tenant bindings. If your workflow is indeed running on Consumption but the Bicep template generated a referenceName structure, you might be dealing with a mixed definition error.

Recommendation:

Manually create a working version of this workflow directly from the Azure Portal.
Extract its code-view JSON and compare it with the JSON produced by your Bicep deployment to ensure Bicep isn't misconfiguring your connection bindings.

Forcing Webhook Re-registration

Because webhook mechanisms rely heavily on active subscriptions established during configuration, anytime you re-authorize an API connection, you must force a refresh.

Verifying Webhook Subscriptions

Please be aware that there is currently no public UI or API endpoint available to directly inspect active webhook subscriptions inside the Bookings or Exchange backend. To diagnose this, you will need to cross-verify across:

The Trigger History execution logs inside your Logic App.
The health state of the API connection resource.
A direct configuration comparison with a standalone portal-built functional test workflow.

I hope these insights help pinpoint the issue.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click ""Comment"".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Julian Ruthberg Olsen 0 Omdømmepoeng

2026-07-01T08:38:57.0166667+00:00

The api-connection account has admin on the booking page. I also confirmed that the connection name property is correct

Answer 2

Michelle-N 20,745 Eksternt personale hos Microsoft Moderator

Hi @Julian Ruthberg Olsen

Thank you for the update. After reviewing the information you've provided, I believe this issue may require a deeper level of investigation than we can perform through the forum. Since I don't have access to the advanced diagnostic tools needed to fully analyze the behavior in your environment, I would recommend opening a support ticket with Azure Support. The engineers can perform a more detailed analysis and work with you directly to identify thusissue. Thank you for your patience.

0 kommentarer