2 results found

1. Idempotent requests

   At the moment, its rather difficult to recover from a network interruption that happens when you send the request to Xero API, and you loose the connection before you receive the response from Xero. There is a fair number of reasons why this could happen at any time.
   In such a situation you really have no way of knowing if your request was even sent fully, or if it was received by Xero, nor what was Xero's response.

   This is not specific to Xero, as all APIs out there have this same problem, as its simply how the web works.

   Best solution to this I've seem so far are Idempotent Requests.

   With each request to Xero API you would include some kind of a unique identifier which only needs to be unique to you, not all of Xero users. For example if you need to send some invoices to Xero and you have each of them already saved in your database, you could send your primary key as your unique identifier as this is something that will not change on your end.

   Xero then reads your request and makes a note of what was requested and saves your unique key along with request params.

   If network goes down at this point, Xero will still know what you requested and prepare a response for you, but will not be able to deliver the response since the network connection is closed now.

   To retry, you just send the same request, with same unique identifier and Xero knows you already requested that, and just returns the cached response, that is was unable to deliver last time.

   In another scenario, if your network goes down even before Xero received your request, next time you send the request, it will be a new one for Xero, and it will be processed as usual.

   So in both cases, when network goes down before and after your request was received by Xero, its safe to retry your request once network connection is restored.

   Stripe is a nice example of an API that supports idempotent requests, which makes working with it much easier and worry free.

   https://stripe.com/docs/api?lang=curl#idempotent_requests

   If you were to try to achieve something like this now, it will not only be impossible to do in all cases, but it would also take a lot more of your time, be much more prone to bugs as you would need a separate system for each document type in Xero, plus it would eat into your rate limit as you would need to query the API first, before you can try sending your request again.

   At the moment, its rather difficult to recover from a network interruption that happens when you send the request to Xero API, and you loose the connection before you receive the response from Xero. There is a fair number of reasons why this could happen at any time.
   In such a situation you really have no way of knowing if your request was even sent fully, or if it was received by Xero, nor what was Xero's response.

   This is not specific to Xero, as all APIs out there have this same problem, as its simply how the web works.

   … more

   87 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   planned  ·  1 comment  ·  General Requests  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Add a "Retry now" button to force webhooks in "Retry" status

   If the webhook listener goes offline, the webhook server will try to send the data with increasing delays up to 24 hours where it will stop.

   The issue is that if our listener crashes during an extended period of time, we might have to wait for an extra long period of time before it is retried.

   Adding a "Retry now" button would allow devs/admins to restore the webhook to their "OK" status much earlier (ie. as soon as the listener has been fixed).

   9 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   planned  ·  2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close