Why does the webhook.execute node in our Architect flow for WhatsApp messages is consistently returning a 409 Conflict error when attempting to create a new incident in ServiceNow? The environment is Genesys Cloud Release 2024-12 (v13.2) deployed in eu-west-2, integrated with ServiceNow Washington DC. We have verified that the ServiceNow REST API endpoint (/api/now/table/incident) is accessible and accepts direct POST requests with the same payload structure from Postman without issues.
The Architect flow triggers on the conversation.create event for digital channels, specifically WhatsApp. The payload construction uses Data Actions to map the conversation details, including the participant’s phone number and initial message text, into the required JSON body for the ServiceNow incident creation. The webhook configuration uses Basic Authentication with a dedicated integration user in ServiceNow that has the itil role and appropriate ACLs configured for incident creation. The timeout is set to 30 seconds, which should be sufficient for the request to complete.
The specific error response from the webhook.execute node includes a status code of 409 and a message indicating that a duplicate record was detected. However, we are not implementing any duplicate detection logic in the ServiceNow side for this specific integration, and each WhatsApp conversation generates a unique correlation ID that is passed as the sys_id in the payload to ensure idempotency. The ServiceNow logs show no corresponding entries for these failed requests, suggesting the conflict might be occurring at the Genesys Cloud level or in the network layer between the two platforms.
We have checked the ServiceNow duplicate rules and confirmed that none are active for the incident table based on the fields being sent. The JSON payload includes the caller_id, short_description, and description fields, all of which are properly formatted. Has anyone encountered a similar issue where Genesys Cloud incorrectly interprets a successful HTTP 201 response from ServiceNow as a 409 Conflict, or is there a specific configuration in the webhook.execute node that might be causing this mismatch? Any insights into debugging the exact point of failure would be greatly appreciated.