Can anyone clarify the exact synchronization interval or potential caching layers affecting the GET /api/v2/trunks endpoint when retrieving real-time session metrics for BYOC trunks?
We are managing a complex environment with 15 BYOC trunks distributed across multiple APAC regions, utilizing specific SIP registration failover logic to handle carrier outages. Recently, while building a custom analytics dashboard to monitor trunk health, we noticed a significant divergence between the active session counts reported by the Genesys Cloud Admin Console and the data returned by the Platform API.
The Admin Console shows 142 active sessions on our primary Singapore trunk, whereas the API response consistently returns 0 for the same trunk during the exact same time window. This discrepancy persists even after forcing a cache invalidation through our internal API wrapper. Given that our outbound routing relies heavily on these metrics for dynamic load balancing, this lag or data inconsistency is causing our failover scripts to make incorrect routing decisions, leading to unnecessary call drops during peak hours.
Here is the relevant snippet from the API response for the affected trunk:
{
"id": "trunk-xyz-123",
"name": "SG-Primary-BYOC",
"status": "ACTIVE",
"sessions": {
"active": 0,
"total": 142
},
"lastUpdated": "2023-10-27T08:30:00Z"
}
The lastUpdated timestamp does not align with the real-time traffic spikes we are observing. We are using the standard REST API endpoints and have verified that our OAuth tokens are valid and have the necessary admin:trunks:read scopes. Has anyone encountered similar latency issues with BYOC trunk metrics specifically in high-concurrency environments? We are considering polling the Telephony Management API instead, but wanted to confirm if this is a known limitation of the Trunk API before refactoring our entire monitoring stack.