Retry failed external API calls using exponential backoff

Options

Hi,

Some times external API calls return errors, when this happens and one of our functions had to use a value that was expected to be returned by the API call (which did not returned it, because it failed), we get an error like: "api_call.response was not found".

I would like to implement exponential backoff retries for my external API calls.


Any ideas on how to implement it in Xano?


Thanks!

Tagged:

Best Answer

  • Ray Deck
    Ray Deck Trusted Xano Expert ✭✭✭
    Answer ✓
    Options

    Sure, you can wrap your API call in a "while" loop that runs until you get good responses, and if it sees a bad response, you can add a "sleep" (utility function) to delay however many milliseconds between the calls. When you see a good response, "break" the loop. You can adjust the sleep to reflect an exponential delay curve or random amounts, and you can decide how many fails you want to permit before your endpoint or background task stops and throws an error instead.

Answers

  • pachocastillosr
    Options

    @Ray Deck thanks for replying!

    So how would you evaluate that a response is good?

    I can imagine something like:

    IF "api_call.response.whateverdata" is not empty
    THEN, it is a good response,
    ELSE, it is a bad response.

    The problem with that is that if the api response was bad and it throws an error, the path "api_call.response.whateverdata" would not even exist (since the external api error response only contained an error message), so the IF function wouldn't even run and it will throw a "api_call.response.whateverdata" was not found error, even before having the chance to run the IF function.

    Taking this into consideration, how would you evaluate that a response is good?

    Thanks

  • Ray Deck
    Ray Deck Trusted Xano Expert ✭✭✭
    Options

    api_call.response.status usually contains the numerical response code. 200 is a standard success code. (3xx is a redirect. 4xx is a communications problem. 5xx is a server error). So I'd use that for your test. I'd treat a non-200 as an error.