Just noticed that the standard REST API endpoints for retrieving real-time trunk status are exhibiting significant latency, occasionally exceeding 45 seconds for a simple GET request. This is impacting our automated failover scripts which rely on polling the trunk health every 10 seconds to detect carrier degradation before it affects call quality. When the latency spikes, our scripts trigger a burst of retries, leading to a cascade of 429 Too Many Requests errors from the Genesys Cloud platform.
We are managing 15 BYOC trunks across AP-SE-2 and US-East-1 regions. The issue seems to correlate with periods of high inbound traffic, suggesting the status endpoint might be querying live session data rather than a cached health state. This is problematic because our failover logic depends on deterministic response times to switch traffic to secondary carriers without dropping active calls.
Environment details:
- API Version: v2 (using the
/api/v2/telephony/providers/edge/trunks/{trunkId}endpoint) - SDK Version: Python 2.15.0
- Trunk Type: BYOC SIP Trunks (15 instances)
- Region: AP-SE-2 (primary), US-East-1 (secondary)
- Failover Logic: Custom Python script polling every 10s
Has anyone else experienced delays when polling trunk status during peak hours? We are considering switching to a webhook-based approach for status changes, but the documentation is sparse on the reliability of trunk:status events for BYOC specifically. We need to know if this is a known limitation of the v2 API or if there is a more efficient way to query trunk health without hitting rate limits. The current setup forces us to implement exponential backoff, which introduces a 2-3 minute blind spot where degraded trunks are not detected, leading to increased call failures. Any insights on optimizing these API calls or alternative methods for real-time trunk monitoring would be appreciated.