What is the standard approach to handle execution timeouts when invoking custom Data Actions from within a Premium App that serves multiple organizations? Our integration leverages the AppFoundry platform to synchronize customer data across disparate CRM systems, utilizing the Platform API to trigger Data Actions via the endpoint POST /api/v2/integrations/data-actions. The architecture involves a Node.js backend (v18 LTS) interacting with the Genesys Cloud SDK for JavaScript (v4.38.0). We are deploying this solution across a multi-tenant environment where the app instance is shared among over fifty distinct organizations. The specific issue arises during bulk synchronization events, where we attempt to execute a Data Action named ‘SyncContactAttributes’ for approximately 500 records in parallel. The request payload includes the data action ID, the organization ID, and a JSON object containing the contact attributes. While individual executions succeed with a 200 OK status, batch operations exceeding fifty concurrent requests begin to fail intermittently. The error response is a 504 Gateway Timeout, returned by the Genesys Cloud edge proxy rather than the underlying Data Action handler. The error body contains a generic message: ‘The server did not receive a timely response from the upstream server.’ We have verified that the Data Action itself completes within two seconds on average by logging execution times directly in the handler code. The timeout appears to be triggered by the aggregate load on the API gateway when processing the burst of requests. We have implemented exponential backoff and jitter in our client code, but the rate of failures remains unacceptable for our SLA requirements. The environment is configured with standard Premium App limits, and we are not hitting the documented rate limit headers (x-ratelimit-remaining) before the timeouts occur. Is there a recommended pattern for throttling Data Action invocations from an external app to prevent gateway timeouts? Should we be batching the requests differently or utilizing a queue-based approach within the Architect flow to mediate the load? Any insights into the internal queuing mechanism for Data Actions in a multi-org context would be appreciated.