Best practices

These HTTP status codes indicate that an error has occurred and the client appears to be at fault. These are not transient failures and are usually not self-correcting. For example, the request may have combined a country, dataset and search type that is not supported or the client may not be authorized to use the service.

Requests that result in client errors from Experian Address Validation should not be retried because they are unlikely to succeed without updating the request.

One exception is the HTTP 429 Too Many Requests response status code. It indicates that you sent too many requests over a specified period of time. Experian Address Validation responds with a HTTP response code of 429 Too Many Requests and a response body similar to the below. Once a client or application reaches this limit, any further requests are blocked until the next time window begins. You can retry your requests as soon as the time window resets.

{
    "error": {
        "type": "https://docs.experianaperture.io/address-validation/experian-address-validation/address-api-reference/status-codes-and-error-responses/",
        "title": "Too Many Requests",
        "detail": "The rate at which you are submitting requests is too high. To protect all customers, your account has been blocked for one minute.",
        "instance": "/address/search/v1"
    }
}

These HTTP status codes indicate that an error has occurred and the server appears to be at fault. For example, connectivity issues via the internet or service issues. Try investigating whether the errors are thrown by your local application stack or if the errors are received from your requests to Experian Address Validation.

Requests that result in server errors from Experian Address Validation should be retried because they may succeed on subsequent attempts.

We suggest a retry strategy that follows the Capped Exponential Backoff pattern. Immediately and constantly retrying requests can have negative impact on our service's recovery if the issue was caused by exceptionally high load on the service. We advise the client waits an amount of time between attempts. The wait time should be increased exponentially after every attempt. We suggest of using 500ms delay as the starting point and then doubling the delay on every attempt. As the backoff time increases quickly and too avoid retrying requests that are no longer relevant, you should cap the number of times your application retries a request. We suggest to do no more then 3 attempts of the same request.