We are encountering a persistent failure in our Architect flow that handles Australian number porting requests. The issue occurs when a Data Action attempts to validate the MSISDN against our internal compliance database before sending it to the ACMA portal.
Environment:
- Subdomain: mypurecloud.com.au
- Architect Version: Latest
- Custom Integration: REST Client Data Action
The Problem:
The flow works intermittently. About 30% of the requests fail with a 500 Internal Server Error from our backend API. The error payload returned by Genesys is generic:
{
"code": "internal.server.error",
"message": "An internal server error occurred. Please try again later."
}
However, checking our backend logs shows the request never reaches our application. It seems to be failing at the Genesys Cloud proxy layer or during the initial handshake. We have verified that the API key used in the Data Action has not expired and has the correct permissions (integration:read, integration:write).
We are using the application/json content type. When we test the same endpoint via Postman with the same headers and body, it succeeds 100% of the time. This suggests the issue is specific to how Genesys Cloud constructs the outbound request or handles timeouts for our APAC region servers.
Has anyone else experienced latency or timeout issues with Data Actions targeting Australian endpoints? We are considering adding retry logic, but I want to understand if there is a known limitation with the mynpurecloud.com.au routing for custom integrations. Any insights on debugging the exact point of failure within the Data Action execution would be appreciated.