I am using a backend service that makes API calls on my behalf. About 9-10 days ago all of the API requests were fine and returned a result but starting yesterday any time I try to make an API request to my sandbox account it gets aborted with
Not valid http result json(upstream connect error or disconnect/reset before headers. reset reason: connection termination)
At the same time, I can make the same request with Postman/Insomnia, and this backend service also is successful making API requests to other services besides Square. It looks like Square does not allow requests from their IPs anymore? Is that even a possibility or a probability? Their customer support is saying that based on their logs it looks like the connection is terminated from your end.
P.S. I attached a screenshot showing what’s going on from my end on the service I’m using.
Hi @yurivaskovski welcome to the forums!
Could you please provide your Square application id and I’ll take a look at the logs on our side?
Is the issue still occurring? In our logs from today I’m only seeing status code 200 for
SearchCatalogObjects with that sandbox app id. There was one 400 ("“Expected body to be a JSON object.”"), but then only 200s afterward.
i just tried a few minutes ago to see if the problem still occurs and it got aborted with the same error. so, what are you saying is that those bad requests I’m having haven’t even reached your servers?
200s are from insomnia/postman testing
Ah sorry I misread; in that case, yes I’m not seeing any hit our servers. The last 200 was about 2 hours and 40 minutes ago, and I do not see another
SearchCatalogObjects request at all since then.
yeah, the 200s are the ones made from insomnia/postman which were made around that time. great, thank you for checking your logs, that just proves that there is nothing wrong on your end as I thought. thanks a lot
so the problem was with headers. the service i’m using is built on Erlang and it seems like after a recent update of Square, i now have to include a header “te” to make that request work and not be rejected on your end. i’m curious what might’ve changed that now required this header to be sent.
Apologies for the delay. Let me check in with some teams on my end, I haven’t heard of anyone needing to add a “te” header. Can you confirm what all endpoints you were hitting besides
SearchCatalogObjects that needed this header?
Sorry for such a long response time. I am using it for Catalog, Payments, Orders, Customers. So, basically, it didn’t matter which endpoint I was using.
Since then, I also have another question:
Could you please help me out with a pattern or a Regex for “uid” parameter of a line item in an order? Thank you
Thanks for the info, I’ll see if our teams know anything about this header.
Not sure about the regex. As far as I know we do not guarantee any specific format or length on those ids.
Hi @yurivaskovski we still haven’t been able to find anything on our end. We have no evidence that a
te header should ever be required. If you’re able to test again, would you be able to trace what your Erlang service is sending us to see if it’s vastly different than Postman?