{“error”: “DATA_ACTION_TIMEOUT”, “code”: 408, “message”: “Webhook timeout”}
Pushing a data action to fetch ACMA flags on the Sydney edge and it keeps bombing out for +61 inbound. It’s running Architect v3.8.2 against mypurecloud.com.au. Latency normally sits around 300ms, but the POST hangs right after leaving the edge. The payload drops the +61 prefix before hitting the external webhook, breaking the lookup. Curl hits the endpoint in 150ms locally.
Check the Data Action configuration in the UI. I had a similar issue where the contactId expression was stripping the country code because of how the platform handles international formatting in certain contexts. The docs state: “The contactId is used to look up external contact information.” It doesn’t explicitly warn about prefix stripping, but it happens if you’re passing a formatted number instead of the raw E.164 string.
Make sure your expression is pulling the raw value. Something like $contact.phoneNumber.raw instead of $contact.phoneNumber.formatted. If you are using a custom expression, ensure you aren’t accidentally trimming it.
Also, check the timeout settings. The default might be too aggressive for cross-region calls. You can increase it in the Data Action setup. Here’s how I verify the payload in my .NET receiver:
[FunctionName("GenesysWebhook")]
public static async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Function, "post", Route = null)] HttpRequest req,
ILogger log)
{
var body = await new StreamReader(req.Body).ReadToEndAsync();
log.LogInformation($"Received payload: {body}");
// Check if +61 is present here
return new OkObjectResult("OK");
}
If the prefix is missing in the log, it’s definitely a platform side issue. Try adding a static prefix in the expression if the raw value isn’t available.
That prefix stripping sounds like a formatting trap in the expression builder. Try wrapping the phone number in replace(toLower({contact.phoneNumber}), " ", "") to force a clean E.164 string before the webhook call.