Bot Analytics API missing BYOC trunk data for APAC region

Architect & Flows
1

Quick question, has anyone seen this weird error? with the Bot Analytics API when querying interactions routed through our Singapore-based BYOC trunks. The trunk_id field returns null despite correct SIP registration and failover logic. We manage 15 trunks across APAC. Endpoint: GET /api/v2/analytics/conversations/details/query. SDK version 1.2.4.

{
 "interval": "2023-10-01T00:00:00Z/2023-10-02T00:00:00Z",
 "group_by": ["trunk_id"],
 "filters": { "direction": "inbound" }
}

Any insights?

2

This looks like a regional data replication lag affecting the analytics store. Try adding a region filter to force the query to hit the APAC endpoint directly.

{
 "interval": "2023-10-01T00:00:00Z/2023-10-02T00:00:00Z",
 "group_by": ["trunk_id"],
 "filters": {
 "direction": "inbound",
 "region": "APAC"
 }
}
3

It depends, but generally…

{
 "interval": "2023-10-01T00:00:00Z/2023-10-02T00:00:00Z",
 "group_by": ["trunk_id", "region"],
 "filters": {
 "direction": "inbound",
 "region": "ap-southeast-1"
 }
}

The suggestion above about adding a region filter is a solid starting point, but there is a nuance with BYOC trunks in the APAC region that often trips up these queries. The analytics store sometimes treats BYOC traffic differently regarding metadata propagation compared to native cloud trunks. When I was wrestling with similar null values for trunk IDs during our quarterly schedule adherence audits, I found that explicitly grouping by region alongside trunk_id forces the engine to resolve the trunk context before applying the null filter.

Also, double-check the region string format. Using APAC might be too broad for the specific Singapore node. Try using the specific AWS region identifier like ap-southeast-1 or whatever your BYOC integration is mapped to in the admin portal. This granularity helps bypass the replication lag mentioned earlier by pinning the query to the exact data shard.

If you still see nulls, verify the SIP registration logs in the BYOC partner portal. Sometimes the trunk_id isn’t being passed back in the SIP headers correctly during the initial handshake, meaning the data never hits the analytics store in the first place. It is not always a Genesys issue; it can be a configuration mismatch on the carrier side. Adjusting the group-by clause as shown above usually resolves the immediate query error, but checking the header mapping ensures the data is actually there for future reports. This approach has saved me hours of debugging during peak scheduling cycles when data accuracy is critical for forecasting.

4

If I remember correctly…

  • BYOC trunks require explicit routing_region in the query, not just region.
  • Update the filter to: "routing_region": "ap-southeast-1".
  • Ensure your OAuth token includes analytics:read scope for that specific cluster.
  • Check if the trunk is registered under a different deployment_id.