Genesys Cloud API 429 Rate Limiting on BYOC Trunk Configuration Sync

Could someone explain why we are consistently hitting HTTP 429 Too Many Requests errors when attempting to synchronize our 15 BYOC trunk configurations via the Platform API?

We have a scheduled automation script running every 15 minutes to validate and update trunk settings across our APAC regions (Singapore and Tokyo). The script calls GET /api/v2/telephony/providers/edge/trunks to retrieve current states and then issues PATCH requests to correct any drift in SIP credentials or outbound routing rules.

The issue started approximately 48 hours ago. Initially, the requests succeeded, but now we are seeing a steady stream of 429 responses with the following header:

Retry-After: 120
X-RateLimit-Reset: 1715623800

We are using the official Genesys Cloud Python SDK version 2.45.0. Our application handles the Retry-After header by implementing an exponential backoff strategy, starting at 1 second and doubling up to 60 seconds. Despite this, the rate limit resets seem to occur faster than our backoff can accommodate, causing the sync job to fail completely after roughly 10 minutes of execution.

This is particularly problematic because our failover logic relies on these configurations being up-to-date. If the primary carrier experiences latency, we need the secondary route to be active immediately. Any delay in configuration sync could result in dropped calls during peak hours (14:00-16:00 SGT).

We have verified that no other processes in our environment are making excessive calls to the telephony endpoints. The only recent change was an update to our Terraform state, which triggered a batch of trunk updates, but that was completed successfully two days ago.

Has anyone encountered a similar issue with the Platform API rate limits for telephony resources specifically? Is there a way to request a temporary increase in the rate limit for our organization, or should we be restructuring our API calls to be more efficient? We are considering switching to webhooks for configuration change notifications, but that seems like a significant architectural shift for what appears to be a transient API issue.