Sometimes API calls fail - your script will fail unless your code is written to adapt to error codes.
This article explains what 429, 500, & 503 error codes are and how to deal with them in your scripts. It is intended for developers using the Intrinio API.
Error Code Overview
If you use the Intrinio API, you should be familiar with the response codes that can be returned. A 200 means everything went well and a 401 means you entered the wrong API keys.
429, 500, and 503 error codes can occur even if your script syntax had succeeded previously. In other words, code that had previously worked with a 200 code could suddenly return an error.
If you had been relying on your script, this could come as quite a shock. But if you have worked with APIs for a while you learn to expect errors.
Why Do These Errors Occur?
APIs rely on servers that serve up the data requested by your API call. These servers have limited resources because, well, servers cost money. Sometimes the servers get overloaded (a 503 error), or the server goofs (a 500 error) or the server has a limit on the number of requests to protect against a 503 error and you went over that limit (a 429 error).
It is possible to reduce these error rates by dynamically scaling server resources, adding more servers in general, and by taking other back end precautions. At Intrinio, we've invested in these solutions to keep the error rate as small as possible. Out of billions of API calls that we serve up, only a few fail.
Still, if your application makes hundreds of thousands or millions of API calls over months or years, a few are going to fail. This is true of any API. At times of high server loads, the likelihood that an API call will fail goes up.
Preventing Script Failure
So, API calls will fail. You can ignore this fact if you are okay with some failed API calls. Perhaps you can just re-run your script or you can wait out times of high server loads. But, if you need your code to run then you need to be able to handle errors.
Different coding languages have different approaches to handling errors. Some languages have a built in "if error" function for this very purpose. Some API wrappers handle errors automatically.
A common approach to handling errors is to retry API calls that fail. This amounts to writing an "if else" statement around your API calls. If the call returns a 200, go on, else, retry it until the maximum number of retries has been reached.
You can see what this looks like in R here:
https://stackoverflow.com/questions/20770497/how-to-retry-a-statement-on-error
Or, a more in depth example for Python:
https://powerfulpython.com/blog/api-retry-patterns/
If you wrap your API calls in a "Try" function, the rare occasions where the server messes up or is overloaded won't cause your script to fail. Instead, it will try again until it succeeds. You can also log the times the script exceeds the maximum number of retries so you know what went wrong.
Solving 429 errors, where your script went over an imposed limit, is as simple as keeping your script from going too fast. Inserting a sleep, or pause, between calls is a common solution as is logging the rate of calls and pausing when it gets too high.