Why does this specific configuration in our outbound routing logic trigger rate-limiting on the analytics reporting endpoints? We are currently managing fifteen BYOC trunks distributed across AP-Southeast-1 and other regional clusters. The environment relies heavily on custom Data Actions to enrich conversation metrics with carrier-specific latency and jitter statistics.
Recently, after updating the SIP registration timeout values to align with new carrier failover logic, we started encountering persistent 429 Too Many Requests errors when querying the /api/v2/analytics/conversations/summary endpoint. This occurs specifically when the query filters include the routingStrategy parameter set to longestIdleAgent combined with our custom BYOC trunk identifiers.
The issue is not consistent across all regions. AP-Southeast-1 trunks, which handle approximately 60% of our call volume, exhibit this behavior within seconds of the Data Action execution. Other regions remain stable. We have verified that the API keys have sufficient permissions and that the request payload size is well within the documented limits. The SDK version in use is 2.1.4 for Python, and we are handling retries with exponential backoff, yet the rate limit persists.
It appears that the platform is treating each enriched metric calculation as a separate API call for rate-limiting purposes, rather than aggregating them. This is problematic because our failover logic requires near-real-time latency checks to decide whether to route calls to a secondary carrier. If the analytics endpoint is throttled, the Data Action fails, and the routing decision defaults to the primary trunk, which may be experiencing high latency.
Can someone clarify if there is a known issue with the interaction between BYOC trunk metadata enrichment and the analytics API rate limits? We need a workaround that does not involve reducing the frequency of our latency checks, as that would impact our service level agreements. The error logs show the request ID req_99887766, which might help trace the specific throttling event. This is critical for our current compliance reporting cycle.