We recommend that you implement our Retry Policy and KeepAlive Best Practices
API error codes and retry recommendation
Error code | Meaning | Recommendation |
---|---|---|
4xx | Client side error | Do not retry, need to fix the problem in the code |
429 | Too many requests | Retry after at least 1 second; avoid bursts of requests. Login requests should be retried only after 5 seconds |
451 | Blocked due to legal reasons | The account or userName is blacklisted by LivePerson Support, please log a support case if you believe this was enabled for incorrect reasons |
5xx | Error on server side | Retry 3 times with 5, 10, 15 second pause between retries |
In addition to the table above, in order to make sure the application can recover from more than 3 consecutive failed requests, as in the case of a service incident or a maintenance activity with a few minutes of downtime, another retry should be introduced for login/socket close/etc.
The retry should be with a longer interval than the previous one, for example every 2 minutes, or you can use Exponential Backoff. This means that the application waits a short time before the first retry, and then exponentially increases times between each subsequent retry. For example, it may retry the operation after 2 minutes, 4 minutes, 8 minutes, and so on.
An example for Exponential Backoff retry in JavaScript can be found here.
Too short intervals or too many retries can have an adverse effect on the target resource or service. This may prevent the resource or service from recovering from its overloaded state, and it will continue to block or refuse requests. This results in a vicious cycle where more and more requests are sent to the resource or service, and consequently its ability to recover is further reduced. Therefore, make sure you do not define intervals which are too short, to give the application time to recover and retry.
If you receive a 429
response code, this means that your request is being throttled due to rate-limiting. If you encounter this behavior, it is recommended that you provide a window of at least 1 second in between subsequent request retries (or 5 seconds for login requests). Clients who submit "bursty" traffic patterns to UMS may face rate-limiting issues, so it is recommended to smoothen traffic to a more distributed pattern whenever possible.
X-RateLimit-Limit: 120 // Limit for the period
X-RateLimit-Reset: 1701311916 // Reset Epoch for the preiod in Milliseconds
X-RateLimit-Remaining: 10 // Requests remaining for the peroid explanatory
The following are detailed 4xx response codes & their meanings:
Internal code | Meaning | Recommendation |
---|---|---|
1 | Account Disabled | Contact LivePerson support |
4 | Other Error | Review the HTTP Status Code |
7 | User Not Found | Verify the userName exists in the account |
9 | Change Password | The user is required to change their password before logging in |
10 | Change Password | The user is required to change their password before logging in |
11 | Account Disabled | The LivePerson AccountID is disabled, contact LivePerson support |
12 | Account Expired | The LivePerson AccountID has expired, contact LivePerson support |
17 | SAML SSO is Enabled | Do not retry, login with username/password is disabled |
18 | SAML assertion invalid | Do not retry, need to fix the problem in the code |
23 | Server is busy. Retry later | Follow LivePerson Retry Policy best practices |
24 | Server is busy | Follow LivePerson Retry Policy best practices, if the issue persists contact LivePerson support |
25 | Invalid domain | Do not retry, need to fix the problem in the code |
26 | Wrong credentials | Do not retry, need to fix the problem in the code |
27 | Account Expired | The LivePerson AccountID is disabled, contact LivePerson support |