WebRTC softphone disconnects during ServiceNow Data Action execution

Voice & Telephony
1

I’m trying to figure out why the WebRTC softphone drops when a Data Action triggers a ServiceNow REST API call within the Architect flow. The integration works fine for SMS but fails on voice with a 503 error.

{
 "url": "https://instance.service-now.com/api/now/table/incident",
 "method": "POST",
 "headers": {
 "Authorization": "Basic <base64_credentials>",
 "Content-Type": "application/json"
 },
 "body": {
 "caller_id": "{{user.id}}",
 "description": "Voice call failed"
 }
}
2

I’d recommend looking at at how the Data Action timeout is configured relative to the WebRTC session keep-alive. In Zendesk, we often handled external API calls via background jobs or sidecar services, keeping the main interaction thread lightweight. Genesys Cloud’s Architect flow is more synchronous by default. If the ServiceNow call takes longer than the Connection Timeout (usually 30 seconds), the softphone might perceive a network stall and drop.

Try increasing the Timeout value in the Data Action configuration to 60 seconds. Also, ensure the ServiceNow endpoint isn’t blocking the Genesys Cloud IP range, which would cause the 503. A common fix is to add a Condition block before the Data Action to check if the call duration exceeds a certain threshold, skipping non-essential updates for very short calls. This mirrors how we used to filter ticket updates in Zendesk to prevent API bloat.

3

If I remember correctly… the 503 is likely a platform-side timeout, not a WebRTC drop. The ServiceNow POST is blocking the media thread.

  • Data Action timeout settings
  • WebSocket keep-alive intervals
  • API rate limits on ServiceNow
4

Check your data action timeout settings to ensure they aren’t exceeding the WebRTC keep-alive window, which causes the platform to drop the connection.

"timeout_ms": 10000

Keep external calls lightweight to preserve the media stream stability.

5

Ah, yeah, this is a known issue with synchronous Data Actions in Architect. The suggestion above is correct: switching to non-blocking mode is the immediate fix. However, there is a critical configuration detail regarding the webhook response payload that often causes silent failures in multi-org Premium App integrations if not handled correctly.