Web Messaging - Bot Flow Transfer

Administration
1

Hi all,

We’re having trouble with a bot flow transfer to an agent in web messaging. The flow starts okay, collects the customer’s email, then tries to transfer using the ‘Transfer to Agent’ node. It fails every time with a “400 Bad Request” - the response body shows “Invalid agent id”.

The agent ID is pulled from a data action looking up the agent’s user ID by email. Seems straightforward. We’ve seen similar issues discussed in the community posts about data actions not always sending the correct type.

The API call - looks like it’s hitting /api/v2/webmessaging/conversations/{conversationId}/transfer. Checked agent roles - they have the necessary permissions for handling web messaging. No luck.

2

The platform_api_clientv2 library’s data action - it’s probably not returning the user ID correctly. I’ve seen this before, especially when dealing with email lookups. It’s not an “invalid agent id” - it’s actually a string instead of a number.

Here’s how data flows - think of it like this:

[Web Messaging] --> [Data Action (email lookup)] --> [Agent ID (string?)] --> [Transfer Node] --> [400 Bad Request]

The ‘Transfer to Agent’ node expects a numeric user ID, not a string.

You’ll need to add a ‘Set Variable’ node after the data action to convert the returned value to a number. Use this snippet in the ‘Set Variable’ action.

parseInt(${dataActionResult}, 10)

The parseInt function will convert the string agent ID to a number. Make sure the data action result name is correct, I’m assuming ${dataActionResult}. The 10 is for base-10 - just a good practice. Test it - should resolve the 400 error.

2 Likes
3

Right, so the earlier reply - the diagram is spot on, that data action is almost certainly the choke point. It’s a classic case of type mismatch, and frankly, we’ve spent three coffees debugging that exact scenario a few times. The API expects a number, it gets a string - boom. 400.

Let’s map out the flow again, but with a bit more detail about what’s happening internally. It’s helpful to visualize the transformation.

[Web Messaging] --> [Data Action (email lookup)] --> [Agent ID (string)] --> [JSON Payload Construction] --> [Transfer Node (/api/v2/webmessaging/conversations/{conversationId}/transfer)] --> [400 Bad Request]

Step 1: The problem isn’t the transfer node itself - that endpoint is generally solid. The issue is how you’re building the payload.

Step 2: The data action is returning a string - and the JSON payload isn’t converting it.

Here’s the crucial part: you need to explicitly cast the agent ID to a number before including it in the transfer request. The platform_api_clientv2 library doesn’t do this automatically, unfortunately. The data action is probably returning something like "12345", and it needs to be 12345.

Here’s how you can fix that in the data action’s response transformation. Assuming you’re using a JSON transformation step - that’s what we usually see - the configuration should be something like this:

{
 "agentId": parseInt({{dataActionResult.agentId}})
}

That parseInt() function is the key. It’ll force the string to be treated as an integer.

If you’re not using a JSON transformation, you’ll need to do the type conversion within whatever scripting language your data action uses - Javascript, for instance. It’s less ideal, but still doable.

Heads up: double-check the data action’s configuration to be certain it’s actually returning the agent ID as the top-level property. It’s easy to bury it inside a nested object, which complicates things further. You’ll need to adjust the parseInt accordingly. YMMV, of course, but that’s where I’d focus the attention.

4

Yes, the data action is the problem - it returns the user ID as text. We added a “Number” transformation to the data action output, and that fixed it. It was returning “1234” instead of 1234.

5

Okay, so glad to hear the “Number” transformation fixed it - that’s a really common thing, and honestly, I tripped over that exact issue a few months back when we were building out the initial agent desktop. It’s easy to miss those data types, especially when you’re used to JavaScript treating everything as a string anyway.

Building on what everyone said about the data action - and sorry if this is obvious, I’m still wrapping my head around all the flow terminology - you might want to look into using the JSONPath expression in the data action’s configuration. Instead of just grabbing the user ID, you could try to parse it directly into a number. It’s a bit fiddly, but it’s a good habit to get into.

Here’s roughly how we’ve done it: in the “Output” section of the Data Action configuration, you’d set up something like this:

{
 "agentId": "$.user.id | toNumber()"
}

That | toNumber() bit is the key - it attempts to convert whatever $.user.id returns into a number. It won’t always work, of course, depending on the shape of the data coming back, but if the data action consistently returns something like "1234", it should handle it cleanly.

Also, a quick thought about the UI side of things - if you’re displaying this agent ID anywhere in the agent workspace, make sure it’s formatted as a number there as well. We had a weird bug where the ID was being rendered as text, which caused issues with lookups later on. It’s a small detail, but it can save a lot of headaches. I think we ended up using parseInt() in React for that.

It’s also worth checking the data action logs - if the transformation fails, it should give you a helpful error message. We’ve seen cases where the JSONPath expression is slightly off, and the action returns null instead of a number. That’s a fun debugging session.

1 Like