Our Callback URL (Custom Features → API → Settings) completely
stopped sending data since 2026-08-31 20:13 JST.
Account: coachinghq
Domain: coachinghq.simplybook.asia
Plan: Premium Plus
===== What we tried =====
Recreated REST API webhook subscriptions - no change
Cleared/re-saved the Callback URL field - no change
Tested with a completely independent endpoint (webhook.site) -
still zero requests received
===== Possibly related =====
Topic #2227: another customer’s integration stopped on the same
date (2026-08-31)
Topic #2229 (teamyoboo): same symptom
===== Our guess (unconfirmed) =====
We switched the Callback URL multiple times during an internal
rehearsal on 8/29-30. It’s possible some delivery attempts failed
and, after exhausting retries, the system stopped delivery for our
account. Just speculation - we can’t verify this ourselves.
Could someone check our account’s backend for anything related?
===== Also in progress =====
We’ve also been in direct contact with SimplyBook support (ticket
ZDW-CTLTH-245) about this same issue, sharing similar findings.
Flagging this forum post in case it helps connect the dots faster.
Thank you, the fix seems to be working. Here’s what we observed:
Around 23:19 JST, a large batch of previously stuck webhook data
started flowing in (bookings created since our issue began on
8/31). Mixed in with this were some empty payloads (see below).
The scenario kept getting deactivated by errors from these empty
payloads, so we had to reactivate it several times.
Then, just now, we made a fresh test booking (w4e3tmvv7) to confirm
things were working normally going forward - and noticed something
unusual:
We received 3 requests within the same second (00:42:53):
Full booking data (booking_id: included) - processed successfully
An empty payload (only client_id, webhook_timestamp,
signature_algo - no booking_id, no notification_type, no
company) - this is not a format we expect or requested, and it
caused an error on our end
Full booking data again (same booking_id) - processed successfully
Two issues here:
The full booking data was sent twice for the same event, causing
duplicate processing on our end
We’re also unexpectedly receiving these empty payloads that don’t
match the documented callback data format (booking_id,
booking_hash, company, notification_type). We saw many of these
throughout the backlog delivery too, not just on this test.
Could you check the logs for booking w4e3tmvv7 around 2026-09-02
00:42:53 JST, and also let us know what’s causing the empty
payloads?
One possible cause we’re wondering about (unconfirmed): we have
BOTH REST API webhook subscriptions AND the legacy Callback URL
configured, both pointing to the same URL. The REST API
subscriptions were something we created ourselves during
troubleshooting today (4 subscriptions: new_client, new_booking,
change_booking, cancel_booking) - we did NOT have these before the
issue started on 8/31. Only the legacy Callback URL was in use
originally.
Could both mechanisms be delivering independently for the same
event, causing the duplicates? If so, we’re happy to delete the
REST API subscriptions since we don’t actually need them - we only
created them while investigating.
Thank you again for the fix on your side - our webhook delivery has
been fully stable since we removed the extra REST API subscriptions
(the duplicate + empty payload issue was caused by those
subscriptions running in parallel with the legacy Callback URL,
confirmed by a controlled test on our side).
Since we have a major system migration planned for 2026-09-07, we
would really like to understand what actually caused the initial
webhook stoppage on 2026-08-31, so we can avoid triggering the
same issue again during the migration.
Could you please share what your team found?
Specifically:
What was the root cause of the webhook delivery stoppage that
started on 2026-08-31 20:13 JST? Was it something in our account
configuration, or a wider issue on SimplyBook’s side?
What was the trigger? On 2026-08-29 to 08-30 (JST), we did switch
the Callback URL back and forth multiple times as part of a
migration rehearsal. Could that sequence of Callback URL changes
have caused the internal state to break? (During the outage,
getLastNotificationUpdate consistently returned false, while
email/SMS notifications continued to work normally - only
webhooks stopped being generated.)
What action did your backend team take to restore delivery?
(Just so we know what kind of recovery is needed if this
happens again.)
Around the same time (2026-08-31), at least two other customers
reported similar webhook/Callback issues on this forum
(topics #2227 and #2229). Are these known to be related?
We ask because on 2026-09-07 we plan to switch the Callback URL to
a new production endpoint (part of a broader system migration). If
Callback URL switching itself is risky, we want to know what safe
procedure to follow.