Yep, that works.

Can you explain why this is necessary? If request.body.dataString is already presented as a string, then why do we need to coerce the type?

Thanks!

To be honest, I cannot. JavaScript is a terrible language regarding data type safety, and at the end you NEVER can rely on any datatype returned by an API. That's the reason why I'm using as often as possible the explicit cast to a String type via String();

Well, enough time has passed that I guess nobody else knows either! 🙂
Thanks for your prompt response, Maik. I'll accept your answer as, ultimately, it did the job.

I highly doubt that has anything to do with JS, and would look at how SN implemented it and how it's data type is set within SN's Java code for interpreting the data type. Because if the variable is named and detailed by SN as a String and it's not returned as one, then that's where the problem lies, not the language.

It should be raised as a SN defect, as it should NOT clear the 'request.body.data' object either when JSON parsing 'dataString', which it does, meaning that it's being set by reference somehow. Thus exposing the coding error on SN side.