Genesys Cloud Analytics API v2 returning empty datasets for BYOC trunk failover metrics in AP-SE-2

NICE CXone API & Integrations
1

Why does this setting in the Analytics API v2 endpoint /api/v2/analytics/conversations/summary consistently return null or empty arrays for outboundCarrierFailover metrics when querying our fifteen BYOC trunks in the AP-SE-2 region?

We are managing a complex multi-carrier setup where SIP registration stability is critical. The environment relies on strict failover logic between primary and secondary carriers. Recent observations indicate that while the Admin UI displays accurate failover counts, the programmatic data retrieval via the Python SDK (version 1.6.4) fails to capture these events accurately.

The issue manifests specifically during high-volume outbound campaigns. When a SIP 408 Timeout occurs on the primary trunk, the system correctly fails over to the secondary carrier. However, the analytics data points associated with this transition are missing from the API response.

Steps to reproduce:

  1. Configure a BYOC trunk in AP-SE-2 with dual-carrier failover enabled.
  2. Execute a test outbound campaign that intentionally triggers SIP 408 errors on the primary carrier.
  3. Verify failover success via the Admin UI audit logs and real-time monitoring dashboards.
  4. Query the /api/v2/analytics/conversations/summary endpoint using the groupBy parameter set to outboundCarrier and outboundCarrierFailover.
  5. Observe that the outboundCarrierFailover field in the JSON response is either null or contains zero values, despite UI confirmation of successful failovers.

This discrepancy complicates our automated reporting pipelines. We require programmatic access to these metrics for SLA compliance reporting. Has anyone encountered similar data synchronization delays or mapping errors between the Genesys Cloud backend analytics engine and the API layer for BYOC-specific fields? Is there a known limitation with how failover events are tagged in the AP-SE-2 region compared to other regions like US-VA-2?

Any insights into the underlying data schema or potential workarounds using raw data exports would be appreciated. We are currently forced to parse SIP logs manually, which is inefficient for our scale.