WebRTC Connection Event Data Action 500 Internal Server Error on ServiceNow Incident Creation

Voice & Telephony
1

Stuck on a persistent 500 Internal Server Error when attempting to create a ServiceNow incident from a WebRTC softphone connection event. The Architect flow triggers correctly upon the webRTC:connection event, capturing the necessary conversation details and agent ID. However, the subsequent Data Action call to the ServiceNow REST API endpoint /api/now/table/incident fails with a server-side error.

The webhook payload is structured according to the Genesys Docs specification, including all required fields for the ServiceNow incident table. The ServiceNow instance is configured to accept POST requests, and direct testing via Postman with the same payload succeeds without issue. This suggests the problem lies within the Genesys Cloud Data Action configuration or the way the payload is being serialized before transmission.

Key details:

  • Genesys Cloud Version: Latest production release
  • ServiceNow Version: Washington DC Patch 3
  • Data Action Type: Webhook
  • HTTP Method: POST
  • Headers: Content-Type: application/json, Authorization: Basic [base64_encoded_creds]
  • Error Response: {"error":{"message":"Internal Server Error","stack":"..."}}

The flow executes without errors up to the Data Action step. The ServiceNow server logs indicate that the request is received but fails during validation, possibly due to unexpected field formats or missing mandatory fields that are not immediately apparent in the Genesys Cloud payload structure. Cross-referencing with the ServiceNow documentation, all mandatory fields are included in the payload.

Has anyone encountered similar issues with WebRTC connection events triggering ServiceNow incident creation? Any insights into potential payload serialization issues or configuration mismatches would be greatly appreciated. The goal is to automate ticket creation for WebRTC sessions that require immediate attention, and this error is blocking that workflow.

2

that 500 is almost certainly snow’s rejecting a malformed json body or missing required fields. dump the request body to a log node right before the data action call and validate it against the incident table schema.

3

check if the serviceNow endpoint is actually returning a 500 or if architect is masking a 400 bad request. try hitting it directly with curl to see the real error response.

curl -X POST https://your-instance.service-now.com/api/now/table/incident \
 -H "Authorization: Basic base64encoded" \
 -H "Content-Type: application/json" \
 -d '{"short_description":"test","caller_id":"sys_id"}'
1 Like
4

The 500 is likely GC masking a payload issue. Architect’s Data Action has strict size limits that ServiceNow often exceeds with full JSON responses. You’ll need to strip the response or switch to a Webhook node if the payload is heavy. Check the flow logs for truncation warnings.

5

it’s likely the payload structure causing the 500. ServiceNow’s incident table is strict about field types. if you’re sending the agent ID as an object instead of a string sys_id, SN throws a server error because it can’t parse it.

try this transformer in your Data Action before the POST. flatten the agent data:

{
 "short_description": "{{ trigger.conversation.short_description }}",
 "caller_id": "{{ lookup_user(trigger.agent.id).sys_id }}",
 "description": "{{ trigger.conversation.notes }}"
}

also, check the Content-Type header. it must be application/json. if you’re sending form-encoded data, SN will reject it hard.

we’ve seen this when the webhook returns extra metadata that SN doesn’t expect. strip the response body in the Data Action config to avoid memory issues or parsing errors on the return trip. check the GC flow logs for the exact request body sent. it usually shows the malformed JSON there.

3 Likes