API calls sometimes fail due to extremely high traffic loads. This is particularly the case when multiple calls per second are sent simultaneously and continuously over an extended period of time. For example and for the sake of mathematical simplicity, say the API is sending calls at a rate of 10 records per second, and the return response is that 5 calls were returned successfully, meaning that 5 of those calls failed: either failed to send, failed to be received, or failed to be responded to by the server, or D - all of the above.
*Note: this is one of the reasons it is recommended to not send multiple calls per second incessantly, but rather stagger the calls by one or two seconds, or longer, as a Best Practice.
An end user can receive a 429 Error message from any server, browser, and application. Depending on the operating system / browser being used, the message can vary slightly:
- 429 error
- HTTP 429
- Error 429 (Too Many Requests)
*Because they all have '429' in common, these errors are most commonly referred to as 429s.
429 Error and his friend, the 414 Error
All end users need to handle instances of 429 Errors based on the protocol established by their organization. 429 Errors are not imposed by the application, but are rather the result of the behavior which has triggered this error message. It is important to note that this is not a failure of the application or server, and thus cannot be remedied from the outside.
In the simplest terms, 429 Errors are rate limit signals that the end user must address. Rate limits are not universal across applications, nor are they set in stone, which is why they can only be addressed by the end user in relation to the instance which has triggered the 429 Error.
Now that we understand 429, let's talk 414 Errors
It is not uncommon for 429 Errors to be accompanied by 414 Errors, which are often presented as: URL Request Too Long (URL & URI). If your API calls and being sent at a rate whereby they cannot be answered in a timely enough manner, 414 Errors are often the result. The URL was too long, or the combination of volume and velocity resulted in being unable to respond quickly enough.
499 Client Closed Request
HTTP Status Code 499: A non-standard status code introduced by Nginx that is returned when the client closed the connection before the server could answer the request, most frequently caused by a client side (end user) timeout. Occurs when a client closes the connection while Nginx is processing the request.
The 4XX Class of Codes are often referred to as Client Error Codes. The HTTP + 4 + XX is an indication that the client (end user) did something wrong. Specifically, there's an error on the client side.
The wonderful development team at L2L will help diagnose and troubleshoot this issue. Fixing 429 Errors will be the first recommendation and will greatly expedite getting you back on your feet again!
If you want to read more about it, here is an article: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429
405 Method Not Allowed error
The Hyper Text Transfer Protocol (HTTP) 405 Method Not Allowed response status code indicates that the server knows the request method, but the target resource doesn't support this method.