Hi all -
I am a relatively new system admin for a small nonprofit and we use Salesforce as our primary CRM and Square for our front desk coffee bar and various service payments that we offer.
I am building automations using Make to sync our Square data - contacts, bookings, and transactions - with Salesforce. I am using Square’s webhooks to send booking.created and booking.updated events to Make but running into some issues with the volume of booking.updated events.
I am receiving many more than expected booking.updated events, sometimes an upward of 5+ events per booking, all containing identical data with the only change being an incremented version number for the booking and an updated modified timestamp.
It even seems like sometimes multiple of a client’s bookings will receive a burst of seemingly-empty updates.
I’ve done my best to check if any integrations created before my time with the org are making unwanted booking updates and have come up empty handed. I can’t entirely rule out user actions at the front desk PoS, but it’s strange that the booking.updated doesn’t carry any visible changes.
Are there any server-side updates that Square is making to bookings that would push a booking.updated event with no visible change to the booking? Or am I just barking up the wrong tree on this? I would just ignore them but we are on a fairly tight integration budget and the quantity of extraneous events is a concern.
Thanks yall!
Good morning and welcome to the forums!
Square’s booking.updated webhook fires for any change to a booking object, including internal system-level updates (i.e., payment state changes, availability recalculations) that don’t alter user-visible fields. The only differences you’ll see are an incremented version and a new updated_at timestamp. If you could post your accounts Merchant ID and App ID I can check our backend logs to see if there are non-system updates hitting your booking APIs.
Just some quick notes in the meantime:
- Make sure you return a 200 response as early as possible when receiving the webhook event so you dont get duplicates sent to you. Sometimes automation engines will be slow to respond to a webhook. A duplicate event is sent if your application has not responded in 10 seconds.
event_id will help you dedupe these calls not booking_id
- Be cautious with the version number as webhooks don’t guarantee order of versions so you might receive version 5 before version 3. Make sure on the Salesforce side you’re storing the last synced version so you only sync the latest version
Thanks for your reply! Good advice with the two tips, I will definitely keep those in mind.
Our merchant ID is (I think, let me know if this is the wrong ID) MLQ1TT3KEDAZW
The App ID is sq0idp–YoXEpUeTxdRanEtlKxKWQ
I just had an especially egregious instance of this occur. Something triggered Square to update seemingly every past booking for a client, triggering 50+ booking.updated event in the span of less than a minute. Some updated bookings were almost a year old. There was no action taken by any staff today on the customer’s profile or bookings.
I can provide more information about this particular incident if it would help pinpoint its cause because it’s becoming a major problem.
Hmm I’m looking through the logs and found some info for you. I stubbed out the IDs and sent you a DM with them so you can find more info.
Lets start with your most recent issue:
It looks like a contact was merged through the dashboard by Team Member {teamMemberId}. That contact {contactId} (and old contacts) had ~70 bookings that all got updated to that contact’s new ID.
To your original post, I was able to track down several instances of webhook payloads that were identical outside of version/updated_at. The webhooks are “working as intended” in terms of something about the booking is being updated, the problem is it isn’t a field that you readily have access to.
For example booking {bookingID} had an order payment process and fired an update 3-4 times with no change in the booking data, whereas your 70 webhooks fired earlier all visibly updated the customer_id.
I’ll see if there is any more info the team wants to relay about that and I’ll post back when they respond.