Square Web hooks making unwanted requests to our server

Hi,

In our square dashboard we have set the Webhook subscription for the following 3 events by adding the url to our server that will be called if one following 3 events gets fired from square:

order.created
order.fulfillment.updated
order.updated

Now the problem we are facing is that these events need to get fired if any order is created or updated for our square merchant account but instead these events gets fired on the daily basis if there is no order created or updated for our square merchant account.

The magnitude of the problem is that on normal days these unwanted hits are coming in the range of few hundred to thousand but now it is coming like 6 requests every 1 second making them tens of thousand to half a million.

So due to these unwanted hits our server gets impacted and load gets increased many a times due to which some times our server gets crashed.

To fix this temporarily we have disabled the square webhooks for now. But due to this our sales gets impacted and currently our business is on verge of closing.

So this is a humble request that if you people can provide us the permanent fix and help us in reviving our business.

Thanks

You should only be getting webhooks that you’re subscribed to from sellers that are using your application. Do you have some example orders that you didn’t expect to get and what’s your application ID? :slightly_smiling_face:

yes let me share the order id that is not there in our system.

Order Id: Yo4kiTHEZ5uy06AB1xaOzFGgsX9YY

App Id: sq0idp-r98WGKqTnmQE6jRc2DSPdg

No idea if this is the problem or not, but it sounds very like your webhook script is not returning a 200 exit code. That forces Square to assume that the hit did not work and it will then repeat the hits continuously, hoping that one of those subsequent hits will then work (ie return 200). This is exactly what you are seeing.

If you are using PHP, as an example, you can set the status code with this line:
http_status_code(200);

To get yourself out of this mess, you could try creating a 2-line file containing:

<?php
exit();

and leave it there for 3-4 hours to flush out all the queued retries. You may also be able to see the problem in the dashboard, the most likely cause being that something at the end of your script is dying with an error, causing a 500 to be returned. You should be able to see this by running a webhook test; you may have made a small change to the script after testing, or it may be a runtime error that only occurs on real data.

I realize that some/most of these hits seem to be coming from Order IDs that are not in your system. I wonder if, when that happens, your script is dying with a runtime error which then causes those hits to be retried continually?

Hi Brian,

In our code we are returning the status 200 as a json response. But looking at the Logs of the webhooks it is still sending hits from square up on a daily basis. Please check the below screenshot:

Could you please suggest why these hits are still coming even if there is no order in the present day?

Thanks

What I was proposing was that Square wasn’t seeing a status code of 200, however, that doesn’t seem likely based on the screens you included in your last post. I haven’t checked, but I’m not sure that returning a status of 200 in the JSON is correct though - might be worth double checking that, I could be wrong.

The other possible scenario is that these orders are coming from another device. Have you done a side-by-side comparison with valid orders coming from your software?

Thirdly, a new thought - how are these webhooks configured? If you’re using the new Webhook Subscription system, and have configured multiple webhook subscriptions, you could end up with a hit being sent by EACH subscription instance, so one transaction could generate 4 hits for the 4 subscription rules. You can very easily see if there are duplicates by using the API entry List Webhook Subscriptions.

Other than that I’m fresh out of ideas! If you do solve it, please let us know as others might find it helpful.

Hi

I have checked the api response and status code, it is set to 200. But the thing is that in the Payload of the webhook event we are receiving the updated status of the order that does not belong to our account or the location.

Please check the below screenshot:

There is no physical or point of sales order with this id: EKMd3N8l5aL1fGXoOxGh9yRkgXOZY

Could you someone please help me understand why we are getting these types of hits that does not belong to our account?

It is like we are receiving parcel came for neighbour, at our address that even multiple times.

Are you OAuth’d to that seller? What’s your application ID? :slightly_smiling_face:

Application Id: sq0idp-r98WGKqTnmQE6jRc2DSPdg

That application is OAuth’d to 1727 Square accounts which is why you’re getting all the webhooks. Any account that the application is OAuth’d to will get all events that you’re subscribed too. :slightly_smiling_face:

Can you please help me understand one more thing:

that the above order Id: EKMd3N8l5aL1fGXoOxGh9yRkgXOZY is not placed through our app (IOS or Vendor), that this record does not exist in our database. So lets suppose if the above order id is connected to one of our vendors to whom we have given the Oauth token then do we have option in the webhook that it only lets the event to trigger for the orders that are placed through our app?

Because if we let webhook to trigger the event to our servers than our server gets over loaded with requests and hence impacted the response time of our APIs.

You’re getting webhooks from that seller cause your application is still OAuth’d to their Square account. So any Square account that you are actively OAuth’d to you will receive events your application are subscribed to. :slightly_smiling_face: