Xero - beautiful accounting software

Xero Developer Help Center

Xero Developer Community

Community > API Endpoints >

Endpoint for posting invoices becomes unresponsive on the 3rd attempt

Started by Order Mate -   in API Endpoints

We have an integration with Xero API and we can export invoices to Xero via our software.

There's been a long-existing issue that we decided to address now. When we do Xero exports (POST method) in our software, it succeeds on the 1st and 2nd export, and then fails on the 3rd and so forth time. By fail, I mean, the endpoint (https://api.xero.com/api.xro/2.0/Invoices) becomes unresponsive. The process just goes on forever and we don't get any response from Xero. I've debugged thoroughly and compared all the requests from when it succeeds and requests from when it fails. The tokens and keys are consistent on all requests and I can't find a reason why it would fail after 2 attempts. To make the export work again, we always need to restart the software.

Our software is written in Java, and to make sure issue is not because of stale object or something, we create a fresh instance of OAuthClient.

I've also tried testing this scenario in Postman but only the GET request succeeds. When doing POST requests, I always get "oauth_problem=signature_invalid&oauth_problem_advice=Failed%20to%20validate%20signature"
I already did the "xero testing environment in postman" thing but I can't make the POST request to work.

Any help would be appreciated as we are dead stuck with this issue. Thanks!
Are you using a private, public or a partner connection? I'm also assuming you're still on oAuth 1.0 correct?
 

Jonathan Mifsud  

Yes we're still on oAuth 1.0.
By connection, you meant the network and internet connection? That depends on our customers. Each customer have their own network setup, but the issue is consistently reproducible.
 

Order Mate  

Any updates on this? If possible, I would also like to know if POST for this endpoint (https://api.xero.com/api.xro/2.0/Invoices) is testable via Postman?
 

Order Mate  

We've figured it out. The http client pool has a default max connection per route limit of 2. Connections are not being properly closed, that's why we always reached the limit. It is now fixed. Thanks!
 

Order Mate