We highly recommend following these best practices when integrating with Mnemonic API.
Retries
While integrating with Mnemonic's API you might have to deal with certain retry-able types of errors, most commonly related to the network problems, or rarely to Mnemonic's server problems.
Clients should implement a retry mechanism for these types of errors as a general best practice. HTTP clients which support automatic retries are generally a preferred option, however make sure that the retry mechanism is configured properly with backoff, jitter and specific types of errors that should be retried.
In cases, when a retry is recommended due to the 429 error (Too Many Requests) clients should pay attention to the Retry-After: <delay-seconds> header sent in the response by the Mnemonic's server. Clients must wait provided number of seconds before repeating the requests. If the delay is not provided in the response, we recommend waiting 1s before retrying the request.
Exponential backoff
Exponential backoff is an algorithm that retries requests to the server based on certain status codes in the server response. The retries exponentially increase the waiting time up to a certain threshold. The idea is that if the server is not responsive temporarily, it is not overwhelmed with requests hitting at the same time when it comes back up.
Most exponential backoff algorithms use jitter (randomized delay) to prevent successive collisions. If you use concurrent clients, jitter can help your requests succeed faster.
Make sure that your HTTP client of choice supports exponential backoffs and is properly configured.
Load testing
It's common for users to prepare for a major release by load testing their systems. We generally discourage implementing load testing on a live production Mnemonic API. Not only you are risking running into rate limiting issues, but also we constantly monitor our systems and may block such bursts of requests to ensure the overall stability of the system.
As an alternative, we recommend building integrations so that they have a configurable system for mocking out requests to the Mnemonic API, which can be enabled for load tests. For realistic results, they should simulate latency by sleeping for a time that you determine by sampling the durations of real live mode Mnemonic API calls, as seen from the perspective of the integration. This approach also allows to simmulate various error response scenarios, which is helpful in ensuring that your integration is capable of handling various edge cases in live mode.