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