How to Manage API Failed Requests: Advanced Solutions with an Egress Proxy

API failed requests can occur for a variety of reasons, no matter how well-designed an API is, failed requests can still occur. API failures disrupt the flow of data and cause frustration for both developers and end-users.

In this article, we will explore the most common reasons behind 3rd party API failed requests and how to handle them effectively from an API consumer stand-point, using an Egress API-proxy.  

Before we dive deep into specific types of failed requests, let’s see...

‍Why is an Egress-proxy a great remedy for failed requests? 

Proxies are generally protocol-aware, often used for various network-related tasks, and are located on the client side of the network. Egress API-Proxy is meticulously crafted for the management of API egress traffic, primarily handling ingress traffic.

‍

Take for example the most basic connectivity issues, like high latency and even timeout, in which case the solution will be just like calling your internet provider support, “try again”. Without an egress proxy you should implement a retry logic everywhere you make an API call. Without advanced logic, a code block that handles retry, will not be in sync with a different part of the code applying the same logic. And in cases of API provider-side problems, all of your calls to this provider will start to retry, which might impact your own applications’ performances severely. 

‍

With an egress proxy, a retry logic will work by default for every timed out connection. And if there are more than X timeouts in a given period of time, just apply circuit breaker, returning the same crafted response for all callers to the same endpoint, making you resilient to connection issues without jeopardizing the overall performance for your application. 

‍

‍‍

‍

Common Causes of Failed API Requests

‍

[1] Rate Limits: A Frequent Culprit

Common case: Rate limits are a common cause of failed API requests. Many API providers impose restrictions on the number of requests a client can make within a specified timeframe. Exceeding these limits can result in denied requests or errors. 

To mitigate this issue: It's essential to monitor your request volume and stay within the rate limits defined by the API provider. Basic mode - setup real-time monitoring on API calls rate and error codes (detecting those 429 as they go). 

Egress proxy solution: With lunar.dev and the more advanced way to mitigate rate limits, you will need to set thresholds (soft or hard) with alerts to know prior to the rate limit. You can also set up prioritization and trigger actions of how your app should act once hitting the rate limit. i.e: prioritize specific API calls, throttle requests at a defined pace.

‍

[2] API Breaking Changes: Adapt or Fail

‍

The case: APIs are not static; they evolve over time to meet changing requirements. However, these changes can lead to compatibility issues and failed requests for clients using older versions of the API. 

To mitigate this issue: Stay informed about any upcoming API changes through documentation or announcements from the provider. Basic solution mode: stay updated with docs and announcements. 

Egress proxy solution: With a proxy you can build and record the API scheme in real time from API calls traffic, and compare diffs to see which fields have changed to detect breaking changes as they occur.

‍‍

[3] Identify: Provider or Integration?

‍

The case: Determining whether the issue lies with the API provider or your integration is a critical step in resolving failed requests. 

To mitigate this issue: Sometimes, providers need quality assurance (QA) and tracking QOS (quality of service) - latency, error rate, availability. Regular monitoring and error tracking tools can help pinpoint the root cause and expedite the resolution process. 

Egress proxy solution:  The proxy is agnostic to any 3rd party API provider or integration, so it can unify all the errors and issues from various providers, unify them, analyze and notify when they occur. Taking it a step further, the proxy would also enable the real-time resolution of such issues in production making this an optimal solution. 

‍

[4] Misleading Status Codes: Hidden Challenge

‍

Common case: A particularly frustrating scenario occurs when API providers return a status code of 200 (OK) while including an error message within the response body. This practice is far from best practice, making error detection challenging. 

To mitigate this issue: Implement robust error handling mechanisms that inspect response bodies for hidden errors, ensuring you catch these issues before they impact your application. 

Egress proxy solution: With the proxy you can inspect requests and identify when an error occurs within the body of the request. The proxy can then (1) take the appropriate action i.e, drop the request or retry request, or (2) transform the requests to inform the client of the error.

‍

[5] Subset Failure: Handling Batch Failures

‍

The common case: In some cases, only a subset of requests within a batch may fail, while the rest succeed. Handling partial processing issues requires careful consideration.

To mitigate this issue: Implement mechanisms to identify and address failed requests within a batch while allowing successful ones to proceed uninterrupted. This approach minimizes disruptions caused by isolated failures.

Egress proxy solution: Enables the implementation of a unified error handling system that consolidates different error formats into a consistent structure. An Egress Proxy simplifies the troubleshooting process by consolidating multiple errors into a single comprehensible format, making it much easier to identify and address such issues promptly.

‍

[6] Downtime or Failed Requests?

‍

Common case: It's vital to distinguish between API failed requests and downtime. Downtime implies a complete unavailability of services, whereas failed requests pertain to individual interactions with the API. 

To mitigate this issue: To effectively manage these situations, proactively implement monitoring tools that can differentiate between the two, allowing you to address each issue appropriately in real-time.

Egress proxy solution: Lunar.dev's Egress Proxy helps you to differentiate between the two and provides effective strategies to mitigate their impact. 

‍

We should mention that in the event of using a proxy make sure like we do at lunar.dev that it’s adding the most minimal latency at the 99th% and failsafe - this will allow requests to bypass the proxy and directly connect to the API provider. This minimizes downtime and ensures that critical operations continue unaffected, and it’s why Lunar.dev is failsafe and fault-tolerant by design. 

‍

‍

Conclusion

All APIs are created with Rate Limiting considerations but not all APIs are created well…with the consumer in mind. 

Not all providers adhere to best practices, making it essential to adapt your integration strategy to handle a wide range of API designs. To proactively manage rate limiting issues it is critical to consider Implementing robust error handling mechanisms that account for these variations as smarter consumers of 3rd party APIs.

‍

It all starts at the integration. The best approach is having a proactive resilience and fail-over policies in place according to defined triggers. When integrating with a new API, ensure that data is transferred correctly and that you are using the API in accordance with its documentation. For ongoing operations, regularly monitor API performance and be vigilant for errors that may arise over time. A proactive approach can prevent issues from escalating.

‍

By understanding the root causes of these failures and implementing appropriate strategies, you can minimize disruptions and ensure the reliability of your applications. 

‍

In summary, don’t let API failures disrupt your operations; say goodbye to the frustration of failed requests and hello to a new era of optimized API consumption. Lunar.dev's Egress Proxy ensures business continuity, provides real-time insights into API health, and simplifies error handling. With Lunar.dev, you'll always know which API calls were made or missed within a given timeframe, so you’ll always be empowered to take immediate action using an easy plug-in configuration.

‍

***

‍

We're aiming for the stars. If you're experiencing any API failed requests, check out lunar.dev's open-source solution * star * us! Or get in touch at info@lunar.dev.