Looking for advice on handling HTTP 429 Too Many Requests errors when polling the /api/v2/telephony/providers/edgeproviders endpoint. We are running a custom health check script that queries SIP registration status for our 15 BYOC trunks across AP-Southeast-1. The script executes every 30 seconds, but we are hitting rate limits consistently after the 10th request in a batch.
The error response includes a Retry-After header, but the values vary between 5 and 15 seconds. This unpredictability disrupts our real-time monitoring dashboard. We have verified that the API version is v2 and the SDK is up to date. The issue persists even when we stagger the requests using exponential backoff logic. It seems the platform treats each trunk query as a separate rate limit bucket.
Has anyone implemented a reliable polling strategy for large-scale BYOC trunk monitoring? We need to ensure accurate uptime reporting without triggering platform throttling. Any insights on optimizing the request frequency or using webhooks for registration state changes would be appreciated. We want to avoid manual intervention during peak hours.