In some instances, API calls might fail. Learn why and how to adapt your code to handle our error codes, in order to "fail gracefully".
What error codes can I expect?
If you have ever developed on top of a RESTful API, you should be quite familiar with the conventional "error codes" and have learned to handle errors appropriately. Codes in the 2xx range indicate success, 4xx category indicates errors in the provided information (such as missing or misused parameters or access restrictions) and 5xx codes imply there's an error with our servers (rarely happens).
Our error response allows you to easily understand why the API call failed and how to mitigate it. You can read about the typical error response in our reference docs.
How can I handle errors in order to prevent script from failing?
We've invested in scale and backend precautions in order to keep the error rate as low as possible. That said, some API calls will fail due to wrong requests parameters or server errors (very rare).
Some failed API calls may not be problematic if you can rerun your script or patiently wait in times of high server loads. However, needing to run your code in a stable manner will require being able to handle these errors. Suggestions to mitigate include writing “if-else” statements, wrapping code in the “try” function so it will try again until it succeeds. A “catch” function can be helpful in logging the response messages in order to better monitor the errors.
How can I prevent "rate-limit exceeded" errors (429)?
To avoid going over an imposed limit, you need to prevent your script from going too fast. Popular methods of doing this include inserting a "sleep", or "pause", between calls, or logging the rate of calls and pausing when it gets too high (using the rate-limiting headers).