Can anyone explain why the Analytics Reporting API returns a 500 Internal Server Error when querying trunk utilization metrics for our BYOC connections in the AP-SE-2 region? We are using the /api/v2/analytics/reporting/query endpoint with a standard request body, but the error only surfaces when the date range exceeds 24 hours. Shorter queries return valid JSON payloads without issue.
The environment details are as follows:
- Platform: Genesys Cloud (PureCloud) v22.4.1
- Region: Asia Pacific Southeast 2 (Singapore)
- Trunk Type: 15 BYOC trunks managed via SIP trunking
- SDK: Node.js SDK v6.14.2
- Error Code: 500 Internal Server Error
- Error Message: “Internal processing error occurred during report generation.”
We have verified that the SIP registrations are stable and there are no carrier-side drops during the queried periods. The issue seems isolated to the aggregation logic for long-duration reports involving multiple BYOC trunks. Is there a known limitation with BYOC metadata aggregation in this region, or should we be using a different endpoint for historical trunk stats?
The docs actually state the 500 error stems from exceeding the default time-window limit for BYOC analytics in AP-SE-2. Do not query ranges over 24 hours in a single call. Split the request into hourly chunks using the granularity parameter. This prevents backend timeout issues during high-load periods.
Have you tried splitting the query into smaller chunks?
The Zendesk equivalent would be paginating large export jobs.
It prevents the backend from timing out on large datasets.
The quickest way to solve this is to adjust the query parameters to align with platform constraints.
- Set
granularity to PT1H for hourly buckets.
- Limit
timeRange to a 24-hour window per request.
- Execute multiple sequential calls for larger periods.
This prevents backend timeouts while maintaining data integrity for BYOC metrics.
I’d suggest checking out at how the bulk export pipeline handles these large datasets, as the Analytics API often fails under similar load conditions. When dealing with BYOC trunk metrics, the backend processing for granularity: PT1H can still trigger timeouts if the underlying recording metadata is not indexed correctly.
Consider using the bulk export API instead for ranges exceeding 24 hours. This approach creates a job that processes the data asynchronously, providing a chain of custody audit trail which is useful for compliance. You can monitor the job status via the bulkExportId and retrieve the final payload from the S3 bucket once complete. This avoids the strict concurrency limits of the synchronous /api/v2/analytics/reporting/query endpoint. Ensure your service account has the analytics:report:read scope and that the timeRange in the export definition does not overlap with existing jobs to prevent serialization errors.