Having some issues getting my configuration to work…
We are encountering significant latency issues when attempting to sync screen recording metadata across multiple Genesys Cloud organizations within our AppFoundry integration. The primary symptom is a 408 Request Timeout when invoking the GET /api/v2/interactions/recordings endpoint with specific query parameters designed to filter recordings by a custom tag. This issue manifests exclusively in our production multi-org environment, where we manage connections for over 50 distinct tenants. The timeout occurs consistently after approximately 90 seconds, which aligns with the default HTTP client timeout settings in our Node.js backend service. We have verified that the OAuth tokens used for these requests are valid and possess the necessary interaction:read scopes. The problem appears to be correlated with the volume of recordings generated in the previous 24-hour period, suggesting a potential pagination or server-side processing bottleneck when handling large datasets across different organizational contexts.
The specific configuration in our AppFoundry manifest includes the screen_recording capability enabled, and we are using the latest version of the Genesys Cloud Node SDK (v4.x). We have attempted to mitigate the issue by reducing the page size and implementing exponential backoff retry logic, but the 408 errors persist. Interestingly, the same API call works without issue in our single-org staging environment, even with similar recording volumes. This discrepancy leads us to believe that the multi-org routing layer or the underlying data synchronization mechanism between the tenant databases and the global metadata index might be introducing unexpected delays. We are also observing intermittent 429 Too Many Requests responses preceding the timeouts, which we suspect might be rate-limiting artifacts rather than the root cause. Has anyone else experienced similar behavior with the screen recording API in high-volume multi-org deployments? We are particularly interested in any workarounds or best practices for efficiently retrieving recording metadata at scale without triggering these timeout conditions.