Can anyone clarify the expected behavior for Data Action executions when triggered from a high-volume Architect flow? We are deploying a premium AppFoundry integration that relies heavily on custom Data Actions to sync customer profiles with our external CRM. The integration uses a dedicated OAuth client with data:write and integration:all scopes.
Under normal load, the Data Actions execute successfully within the 30-second timeout window. However, when we process bulk updates for queues exceeding 5,000 contacts simultaneously, the Architect flow begins to fail consistently. The error manifests not as a timeout, but as a 502 Bad Gateway returned by the Genesys Cloud platform API.
Specifically, the call to POST /api/v2/integrations/{integrationId}/dataactions/{dataActionId}/execute fails. The request payload is well within the 1MB limit, and the target CRM endpoint is healthy and responding in under 200ms. We have verified this by monitoring the external logs. The issue appears to be an intermediate layer within Genesys Cloud rejecting or dropping the connection after a certain concurrency threshold is met.
We are currently testing in the us-east-1 region. The Architect flow is set to ‘Execute Immediately’ with no retry logic, as we assume the platform handles rate limiting gracefully. According to the Data Actions Execution Limits documentation, there should be a soft limit based on tenant tier, but we are not seeing any 429 Too Many Requests errors, which suggests the requests are being dropped before they even reach the rate limiter.
Is there a hidden concurrency cap for Data Action execution per tenant or per OAuth client? We are considering implementing a manual throttle in the Architect flow using delay steps, but we want to confirm if this is a known platform limitation or a configuration issue on our end. Any insights into the internal queuing mechanism for Data Actions would be appreciated.