Looking for advice on optimizing the response time for the /api/v2/telephony/providers/edges/{edgeId}/trunks/{trunkId} endpoint when querying health status for our 15 BYOC trunks across the APAC region. Specifically, we are experiencing intermittent 504 Gateway Timeout errors when polling this endpoint every 60 seconds from our internal monitoring dashboard hosted in Singapore (Asia/Singapore timezone). The latency spikes appear to correlate directly with peak call volumes between 09:00 and 17:00 SGT, particularly when failover logic is triggered for our secondary carrier in the US1 region.
The request headers include valid OAuth2 tokens with the telephony:trunks:view scope, and the IAM roles are confirmed identical to our PSTN trunk queries which return within 200ms consistently. However, the BYOC trunks, specifically those configured with complex SIP registration keep-alive settings, seem to trigger a backend validation that exceeds the gateway timeout threshold. We have verified that the SIP credentials are fresh and the registration state is REGISTERED on the Genesys Cloud side via the Admin UI, yet the API response consistently fails during these high-concurrency windows.
Has anyone implemented a caching strategy or a different polling mechanism to bypass this gateway bottleneck? We are currently using the Node.js SDK v2.14.0, but switching to direct REST calls yielded identical timeout results. The error response body is empty, providing no insight into whether the timeout occurs at the load balancer level or during the actual trunk status retrieval from the carrier interface. Given that we manage multi-region failover logic, accurate real-time trunk health is critical for our outbound routing decisions. Any insights into rate-limiting configurations specific to BYOC trunk endpoints or recommended polling intervals that balance data freshness with API stability would be greatly appreciated.