URGENT: Webhook events are not triggered when a meeting is scheduled (Pro Plan, Workspace Owner)

I am using SimplyMeet on a Pro plan as the Workspace Owner.

I am trying to receive meeting.scheduled events via webhook (tested through Make integration).

What I have verified:

  • The webhook URL works correctly when triggered manually (returns “Accepted” and the automation in Make runs).

  • The booking type is active.

  • The meeting is booked via the standard booking page (not iframe).

  • The meeting is assigned to me (no team events, no round robin).

  • The webhook shows as “Active”.

  • The meeting is booked after the webhook was created.

However:

  • No webhook event is triggered when a meeting is scheduled.

  • There is no delivery history.

  • No HTTP request appears to be sent at all.

This suggests that the webhook event is not being dispatched by SimplyMeet.

Could you please check whether webhook event dispatching is correctly enabled for my workspace and account?

Thank you.

We previously sent webhook events to the first registered webhook URL in our system. Since you added multiple webhooks for the same event, we are now sending webhook events to the most recently added URL.

The logs below show the requests sent from our system prior to the update. Going forward, we will restrict the ability to register multiple webhooks for the same event.

[2026-02-20 14:10:25] app.ERROR: Client error: POST https://****/dv7*******jigwt17 resulted in a 410 Gone response
[2026-02-20 14:10:30] app.ERROR: Client error: POST https://****/dv7*******jigwt17 resulted in a 410 Gone response
[2026-02-20 14:15:56] app.ERROR: Client error: POST https://****/m******0hshsmyag resulted in a 410 Gone response: There is no scenario listening for this webhook.
[2026-02-20 14:19:36] app.ERROR: Client error: POST https://****/m******0hshsmyag resulted in a 410 Gone response: There is no scenario listening for this webhook.
[2026-02-20 14:21:42] app.ERROR: Client error: POST https://****/m******0hshsmyag resulted in a 410 Gone response
[2026-02-20 14:34:26] app.ERROR: Client error: POST https://****/dv7*******jigwt17 resulted in a 410 Gone response: There is no scenario listening for this webhook.
[2026-02-20 14:34:32] app.ERROR: Client error: POST https://****/dv7*******jigwt17 resulted in a 410 Gone response: There is no scenario listening for this webhook.

Thank you for the clarification regarding webhook routing behavior.

To ensure a clean and stable setup going forward, I would like to align on the following approach and ask for your confirmation that this is the correct and recommended procedure on your side.

At the moment, although I have registered a new webhook URL and blocked all previous ones in the UI, the newest webhook endpoint is not receiving any events when a meeting is scheduled. Based on my understanding, this suggests that older webhook registrations may still exist in the backend and may still be influencing event routing.

Since I am only able to block existing webhook registrations in the UI — but not fully delete them — I would propose that you perform a complete backend reset of all webhook registrations for my workspace, specifically for:

  • meeting.scheduled

  • meeting.rescheduled

  • meeting.canceled

The objective would be to fully remove all legacy and previously registered webhook endpoints (not just block them), so that we start from a completely clean state without any residual routing logic.

After this reset:

  1. I will register exactly one webhook per event via the Make integration.

  2. I will not create additional connections or duplicate registrations.

  3. Each event (scheduled, rescheduled, canceled) will be connected to its own dedicated scenario in Make.

  4. No further webhook URLs will be created or modified unless necessary.

If you agree that this is the correct approach, please proceed with the backend cleanup and confirm once all legacy webhook registrations have been fully removed.

I would appreciate a confirmation once this has been completed so that I can immediately run a new test booking to verify proper event delivery.

Thank you for your support.

I wanted to let you know that we have gone ahead and removed all previously registered webhook endpoints from our backend for your workspace. Your account now starts from a completely clean state with no residual webhook registrations.

That said, we would like to clarify an important point: the Make.com integration is a third-party service, and the configuration and behavior of webhook connections within Make scenarios falls outside of our scope of support. We are not involved in how Make.com routes, processes, or handles webhook events on their end.

Webhook functionality on our side works as documented here: Webhooks - SimplyMeet.me

Once you have set up your new webhook registrations, please run a test booking. If events are still not being delivered to your Make.com scenarios, we can provide you with our request logs on our end so you can verify whether the events are being sent successfully from SimplyMeet.me. If the logs confirm that events are being dispatched correctly, the issue would then need to be investigated directly with Make.com support.