Analytics API 429 Rate Limiting on Multi-Tenant Data Sync

Trying to understand why our multi-tenant AppFoundry Premium App is hitting unexpected 429 Too Many Requests errors when polling /api/v2/analytics/conversations/details for high-volume orgs.

We have a certified AppFoundry Premium App deployed across over 50 distinct Genesys Cloud organizations, handling data synchronization for our partner customers. The application uses the platform_api specialization to aggregate conversation analytics for a unified reporting dashboard. Recently, several clients have reported data latency issues, and our internal logging shows a significant increase in HTTP 429 responses when querying the /api/v2/analytics/conversations/details endpoint. This is occurring despite our implementation of exponential backoff and jitter, as recommended in the platform documentation. The requests are made using the standard OAuth 2.0 client credentials flow, with separate tokens for each organization to ensure isolation. We are seeing these rate limit errors even when the request frequency is well below the documented limits for our tier. Specifically, we are polling every 60 seconds for the last 24 hours of data, which should be within acceptable bounds. However, the error responses include a Retry-After header that is often longer than expected, causing our sync jobs to fall behind. We have verified that the issue is not isolated to a single organization but appears across multiple tenants with high call volumes. We are using the latest version of the Genesys Cloud SDK for Node.js, and we have confirmed that our API keys have the necessary permissions for analytics:read. We have also checked for any recent changes in the API rate limiting policies, but nothing seems to have changed. We are looking for insights into whether there are hidden rate limits for multi-tenant apps or if there is a specific configuration we are missing. Any advice on how to optimize our polling strategy or handle these rate limits more effectively would be greatly appreciated. We are also open to suggestions on alternative endpoints or methods for retrieving this data that might be more resilient to rate limiting.