Merge pull request LivePersonInc#835 from mpaauw/update-rate-limiting…

…-policies

Update rate-limiting policies.

pages/documents/ClientSideConfiguration/MessagingWindowAPI/APIReference/overview.md

@@ -222,7 +222,9 @@ In order to retrieve the Agent's public profile during a conversation (which is
 
 ### Rate-Limiting
 
-These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in milliseconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 ### Other APIs
 

pages/documents/GettingStarted/Retry Policy Recommendation.md

@@ -27,6 +27,7 @@ Below you can find LivePerson best practices to handle errors:
 | 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 |
 | 5xx          | Error on server side  | Retry 3 times with 5, 10, 15 second pause between retries |
 
 
@@ -38,6 +39,8 @@ An example for Exponential Backoff retry in JavaScript can be found [here](https
 
 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. 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.
+
 ### KeepAlive
 
 Some services require you to send periodic requests in order to keep your session alive.

pages/documents/RealTimeData/MessagingOperationsAPI/methods/messaging-conversation.md

@@ -18,7 +18,9 @@ Messaging Conversation is calculated using bucket aggregation techniques where e
 
 **Example**: If the time is now 13:29 and time frame is 7 minutes the API will use 2 buckets: 13:25 and 13:30. In other words in practice the time of the data is not 13:22-13:29 but 13:20-13:29.
 
-*Note*: this method is subject to Rate Limiting. This means that the maximum number of concurrent requests is limited on the server side. As most requests are in milliseconds, the likelihood of your requests actually encountering an issue is rare but should that happen, you can expect to receive a 429 Status Code from the server.
+*Note*: These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 ### Retrieving Messaging Conversation Data by Account and Skills
 

pages/documents/RealTimeData/MessagingOperationsAPI/methods/messaging-csat-distribution.md

@@ -18,7 +18,9 @@ Messaging CSAT Distribution is calculated using bucket aggregation techniques wh
 
 **Example**: If the time is now 13:29 and time frame is 7 minutes the API will use 2 buckets: 13:25 and 13:30. In other words in practice the time of the data is not 13:22-13:29 but 13:20-13:29.
 
-*Note*: this method is subject to Rate Limiting. This means that the maximum number of concurrent requests is limited on the server side. As most requests are in milliseconds, the likelihood of your requests actually encountering an issue is rare but should that happen, you can expect to receive a 429 Status Code from the server.
+*Note*: These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 ### Retrieving Messaging CSAT Distribution API by Account and Skills
 

pages/documents/RealTimeData/MessagingOperationsAPI/methods/messaging-current-queue-health.md

@@ -19,7 +19,9 @@ Retrieves the information about the current messaging queue state (and all its r
 
 1. The messaging queue data is currently not available by default, in order to enable the data flow please contact your account manager.
 
-2. This method is subject to Rate Limiting. This means that the maximum number of concurrent requests is limited on the server side. As most requests are in milliseconds, the likelihood of your requests actually encountering an issue is rare but should that happen, you can expect to receive a 429 Status Code from the server.
+2. These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 3. **Limitation**: in order for the queue data to appear, there must be at least one agent logged in to LE.
 

pages/documents/RealTimeData/MessagingOperationsAPI/methods/messaging-queue-health-by-group.md

@@ -17,7 +17,9 @@ Retrieves the information about the current messaging queue state (and all its r
 
 1. The messaging queue data is currently not available by default, in order to enable the data flow please contact your account manager.
 
-2. This method is subject to Rate Limiting. This means that the maximum number of concurrent requests is limited on the server side. As most requests are in milliseconds, the likelihood of your requests actually encountering an issue is rare but should that happen, you can expect to receive a 429 Status Code from the server.
+2. These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 3. **Limitation**: in order for the queue data to appear, there must be at least one agent logged in to LE.
 

pages/documents/RealTimeData/MessagingOperationsAPI/methods/messaging-queue-health.md

@@ -18,7 +18,9 @@ Retrieves information about the state of the queue (with all related metrics) fo
 
 1. The messaging queue data is currently not available by default, in order to enable the data flow please contact your account manager.
 
-2. This method is subject to Rate Limiting. This means that the maximum number of concurrent requests is limited on the server side. As most requests are in milliseconds, the likelihood of your requests actually encountering an issue is rare but should that happen, you can expect to receive a 429 Status Code from the server.
+2. These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 3. **Limitation**: in order for the queue data to appear, there must be at least one agent logged in to LE.
 

pages/documents/RealTimeData/OperationalRealtimeAPI/methods/agent-activity.md

@@ -28,7 +28,9 @@ For each state, the following is indicated:
 If no custom Away state reasons are configured, the 'reasons' field will be returned as an empty array.
 
 *Note*: 
-1. This method is subject to Rate Limiting. This means that the maximum number of concurrent requests is limited on the server side. As most requests are in milliseconds, the likelihood of your requests actually encountering an issue is rare but should that happen, you can expect to receive a 429 Status Code from the server.
+1. These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 2. Agent states are calculated by the millisecond but presentation is in seconds. Therefore, there might be a 1 second difference between agent states and agent states total.
 

pages/documents/RealTimeData/OperationalRealtimeAPI/methods/current-queue-state.md

@@ -17,7 +17,9 @@ Retrieves the current queue state related metrics at the skill level:
 •   Current available slots
 •   Current max wait time in queue in milliseconds (version 2 and above)
 
-*Note*: this method is subject to Rate Limiting. This means that the maximum number of concurrent requests is limited on the server side. As most requests are in milliseconds, the likelihood of your requests actually encountering an issue is rare but should that happen, you can expect to receive a 429 Status Code from the server.
+*Note*: These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 ### Request
 

pages/documents/RealTimeData/OperationalRealtimeAPI/methods/engagement-activity.md

@@ -18,7 +18,9 @@ Retrieves engagement activity-related metrics at the account, skill, or agent le
 
 *Example: If the time now is 13:29 and time frame is 7 minutes, the API will use 2 buckets: 13:25 and 13:30. In other words, in practice the time of the data is not 13:22-13:29, but 13:20-13:29.*
 
-*Note*: this method is subject to Rate Limiting. This means that the maximum number of concurrent requests is limited on the server side. As most requests are in milliseconds, the likelihood of your requests actually encountering an issue is rare but should that happen, you can expect to receive a 429 Status Code from the server.
+*Note*: These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 ### Request
 

pages/documents/RealTimeData/OperationalRealtimeAPI/methods/queue-health.md

@@ -18,7 +18,9 @@ Retrieves queue-related metrics at the account or skill level.
 
 **Example**: If the time now is 13:29 and the time frame is 7 minutes, the API will use 2 buckets: 13:25 and 13:30. In other words, in practice the time of the data is not 13:22-13:29, but 13:20-13:29.
 
-*Note*: this method is subject to Rate Limiting. This means that the maximum number of concurrent requests is limited on the server side. As most requests are in milliseconds, the likelihood of your requests actually encountering an issue is rare but should that happen, you can expect to receive a 429 Status Code from the server.
+*Note*: These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 ### Request
 

pages/documents/RealTimeData/OperationalRealtimeAPI/methods/sla-histogram.md

@@ -18,7 +18,9 @@ Retrieves the distribution of visitors’ wait time in the queue, before an agen
 
 *Example: If the current time is 13:29 and the required time frame is 7 minutes, the API will use 2 buckets: 13:25 and 13:30. The time of the collected data is actually not 13:22-13:29, but 13:20-13:29.*
 
-*Note*: this method is subject to Rate Limiting. This means that the maximum number of concurrent requests is limited on the server side. As most requests are in milliseconds, the likelihood of your requests actually encountering an issue is rare but should that happen, you can expect to receive a 429 Status Code from the server.
+*Note*: These methods are subject to Rate-Limiting policies. This means that the maximum number of concurrent requests is limited on the server side. As most incoming requests are measured in seconds, the likelihood of your requests actually encountering an issue is rare; however, if you do encounter a limit, you can expect to receive a 429 status code in an error response from the server.
+
+If your request is throttled in this manner, it is recommended that you provide a window of at least 1 second in between subsequent request retries. 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.
 
 ### Request