The 204 status is misleading here. It just means the API accepted the request, not that the data landed in the participant’s context correctly. The issue is usually how the key is structured or how you’re reading it back.
In Studio, “Set Participant Data” expects the key to follow a specific naming convention if you want it to be accessible as a variable in later nodes. If you just dump raw JSON into the data object, it often gets buried in the session metadata rather than being exposed as a simple variable.
Try this structure for the Set Participant Data action configuration:
{
"key": "customVar",
"value": "{{webhookResponse.customVar}}"
}
Don’t wrap it in a data object inside the action config itself. The action handles the wrapping. You pass key/value pairs.
Also, check how you’re reading it. If you’re trying to use it in a subsequent Data Action or Expression, you need to reference it as {{participantData.customVar}}. Not just {{customVar}}.
If you’re still seeing null, add a Debug node right after the Set Participant Data action. Log the entire participantData object. You’ll likely see the key is there, but maybe under a different namespace or with a typo.
One common gotcha is case sensitivity. customVar is not the same as CustomVar. Studio variables are case-sensitive.
If the webhook is returning an array, you’ll need to pick an index first. {{webhookResponse.data[0].customVar}}.
Here’s a quick snippet to verify the structure in a debug log:
// Pseudo-code for what's happening in the background
session.participantData.set("customVar", "test123");
// Access later
let val = session.participantData.get("customVar");
If you’re using the REST Proxy to set this via an API call instead of the native action, make sure you’re hitting the /api/v2/interactions/instances/{id}/participantData endpoint with the correct scope. But stick to the native action for IVR flows if possible. It’s less error-prone.
Check the debug logs. That’s usually the fix.