So we’ve been trying to build a proper SLA performance report - specifically, tracking average speed of answer against target, broken down by queue - and the analytics API is just… not cooperating. The /api/v2/analytics/reports/sla-performance endpoint is fine for high-level numbers, but we need the conversation details to see why things are slipping, and that’s where it gets messy. The documentation suggests combining the SLA report with conversation detail queries, using the conversationId to join the datasets, which is obvious, but the detail query keeps hitting pagination limits before we can even get a full picture. We’re on Genesys Cloud v85.0.0, and the python script doing the pulling looks like this:
import requests
import pandas as pd
base_url = "https://api.genesyscloud.com/v2"
token = "YOUR_TOKEN" # obviously replace this
headers = {"Authorization": "Bearer " + token}
def get_sla_data(queue_id, start_date, end_date):
sla_url = f"{base_url}/analytics/reports/sla-performance?queueId={queue_id}&startDate={start_date}&endDate={end_date}"
response = requests.get(sla_url, headers=headers)
return response.json()
def get_conversation_details(conversation_ids, start_date, end_date):
all_details = []
page_size = 100 # max allowed, of course
offset = 0
while True:
detail_url = f"{base_url}/analytics/conversations/details?conversationIds={','.join(conversation_ids)}&startDate={start_date}&endDate={end_date}&pageSize={page_size}&pageNumber={offset+1}"
response = requests.get(detail_url, headers=headers)
data = response.json()
all_details.extend(data['results'])
if data['nextPage'] is None:
break
offset += page_size
return pd.DataFrame(all_details)
# Example usage
queue_id = "YOUR_QUEUE_ID"
start_date = "2024-01-01"
end_date = "2024-01-08"
sla_data = get_sla_data(queue_id, start_date, end_date)
conversation_ids = [item['conversationId'] for item in sla_data['results']]
# This is where it dies.
conversation_details = get_conversation_details(conversation_ids, start_date, end_date)
print(conversation_details)
The problem isn’t the code itself - it’s working as designed, hitting the API, processing the results, and handling pagination. It’s just that the number of conversations associated with the SLA report is consistently high enough that we’re making dozens of requests, and the API is throttling us before we can pull everything. From what I’ve seen, the conversationIds parameter has a limit, meaning you can’t just shove thousands of IDs in there, and the pagination on the detail query is… well, it’s the standard pain point. We could move faster if they’d just increase the pagination limits, or provide a way to query SLA performance with conversation details included. It’s just… a bit rough. Ship it.