Architect Event Stream - Unexpected Payload Format

How does Event Streams handle data types? We’ve got an Architect flow publishing to a webhook, expecting a simple string, but it’s sending something else.

genesyscloud-client-app-sdk handles the event stream payload formatting - thought it would just pass the string as-is. Flow looks like this: a simple data action with a text variable mapped to the webhook. No transformation happening.

The webhook endpoint is just doing jack all - logging the raw request body. Here’s what we’re seeing:

{
 "event": "data.action.execute",
 "data": {
 "actionId": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
 "payload": {
 "type": "string",
 "value": "this is the text"
 }
 }
}

It’s wrapping the string in a nested payload object with a type and value. We need just "this is the text". Is there a setting somewhere? Or is this just how it works, and we need to parse this on the receiving end? ymmv.

The Architect version is 2023.11.17. The endpoint is using HTTPS. We’re calling the webhook integration endpoint. Long story short, this is causing issues with the integration.

1 Like

This is happening because the data action isn’t just passing the string - it’s wrapping it in a JSON object. The webhook receives a JSON payload, even if the variable itself is simple text.

The SDK does handle event payloads, yes, but this is a data action within an Architect flow - different thing. The data action’s behaviour is to always send JSON.

To get just the string, you need to transform it before the webhook. Try adding a set variable action right before the webhook. In the set variable action, set a new variable to the value of your existing text variable, but use an expression like this: {{your_text_variable}}. This forces the flow to treat the variable as a string.

Alternatively, you can handle the JSON on the webhook side. If your webhook endpoint is in python, you’ll need to parse the incoming JSON:

import json

def lambda_handler(event, context):
 body = json.loads(event['body'])
 string_value = body['data']
 print(string_value)
 return {
 'statusCode': 200,
 'body': json.dumps('OK')
 }

edit: took like 2 hrs to figure this out last month for one client. It’s a common point of confusion.

3 Likes
{
 "dataAction": {
 "parameters": {
 "body": "{{flow.variable.your_text_variable}}"
 },
 "mimeType": "text/plain"
 }
}

The data action defaults to application/json, even with a text variable. Explicitly set the mimeType parameter to text/plain in the data action’s configuration - that’ll pass the string directly through, bypassing the JSON wrapper. We’ve seen this trip up a few integrations.

The mime type fix in the reply above is correct - that’s the usual culprit. But the data action’s content type isn’t the only place this happens.

Architect event streams also wrap the payload in a top-level JSON object regardless - even with text/plain. It’s a small thing, but it adds an extra layer of nesting.

To strip that, you’ll need a second data action - a transformation. Use a JSON parser to extract the value. The configuration looks like this:

{
 "parameters": {
 "body": "{{dataAction.1.response.body.data}}"
 },
 "mimeType": "text/plain"
}

dataAction.1 refers to the first data action in the flow. response.body.data is where the original value lands. This pulls the string out of the wrapper. We’ve run into this with a few integrations passing data to external systems. Just a hunch, but it’s worth checking.

It’s like a Russian nesting doll - layer after layer of JSON when all you want is the data. That’s Architect event streams for you. The mime type fix is fine, but you’ll still need to peel off that outer wrapper.

Here’s a transformation data action to get to the actual value - we’re running around 300 agents and ran into this last month.

{
 "type": "JsonParser",
 "input": "{{flow.variable.your_data_action_output}}",
 "rules": [
 {
 "path": "$.data",
 "output": "{{flow.variable.stripped_value}}"
 }
 ]
}

N