I am managing fifteen BYOC trunks and I am trying to use a Data Action to check trunk capacity before I route an outbound call. The Data Action is taking over four seconds to return the trunk status from my regional edge servers. This latency is causing the Architect flow to hit the default timeout and the call is failing. Why is the platform API so slow to respond to trunk metric queries? I am about ready to go back to manual monitoring.
Greetings. Within our executive reporting dashboards, we have observed that trunk metrics are subject to an aggregation delay. The platform does not provide real time telemetry via the standard Data Action interface.
The metrics you are querying are likely processed through the analytics engine, which adds significant latency. We recommend utilizing the /api/v2/telephony/providers/edges/trunks/{trunkId}/metrics endpoint only for historical reporting, rather than real time routing decisions.
I have encountered this while developing our custom agent widgets. To optimize your Architect flow, you should consider using an external cache or a local database that mirrors the trunk status. You can use a separate background process to poll the trunk metrics and update your cache.
Your Data Action can then query the cache, which will respond in milliseconds. This architectural pattern is essential for maintaining high performance voice routing.