1 ACCEPTED SOLUTION
If you're referring to the response schema, I can't find a way around this issue directly in the HTTP action. Usually, you can use a JSON sample to work around this blocker, but when using a JSON sample with "first name", Workato automatically changes it to "first_name".
However, there are a couple things that do work...
First, you can access the key directly with bracket notation. This is a little clunky, but it works.
This message imitates the API response:
And then you can access it like this:
Output:
Second, (definitely the better option) you can feed a sample JSON with spaces into the JSON parser, and it will parse it without issue.
It still replaces the spaces with underscores, but this action provides data pills that retain the expected value.
Output schema:
So if I do this:
I get this:
Hope this helps!
Hi gary1,
Thank you for the break down. I think I see where the confusion is. Your explanation is for how to handle the HTTP response but my issue is with the HTTP request.
For the request I need to send a field with a field name of "First Name" so that the endpoint of the request can process it. "First Name" with a space is what the logic of the endpoint is expecting. However, Workato's HTTP request does not accommodate sending the name with a space. Instead it supports "FirstName" and "First_Name". When I use "FirstName" the field name of the request body schema (image attached) 
Request body using "FirstName"in Workato's HTTP appears to separate the First from Name (see image) 
in the input field name but when received at the webhook endpoint the name appears as "FirstName". Your solution would work if I controlled the logic at the receiving end but I do not and am trying to conform to the endpoint's standard.
Request body using "FirstName"in Workato's HTTP appears to separate the First from Name (see image) in the input field name but when received at the webhook endpoint the name appears as "FirstName". Your solution would work if I controlled the logic at the receiving end but I do not and am trying to conform to the endpoint's standard. Thank you again for your help.
Got it, thanks for all of the info. I think I have this figured out.
If you create the request body by providing a JSON sample, you can bypass this blocker. I tested this out using a recipe with an HTTP action using a multi-part form to make a POST call to an API endpoint, and then reviewing how the payload was received.
First, on the request body schema of the HTTP action I clicked "Use JSON" and to provide an example of how I want my payload to be structured:
I entered this:
It created this, which is misleading because it added the underscore to the label:
However, if you look at the schema, it has a details.real_name value of "test test" which is actually how the field gets encoded and sent in the API call:
Next I made an API call to an internal endpoint (with a value of "123").
I logged the message three different ways to be absolutely certain it was retaining the space:
To JSON:
To string:
Raw:
And then I even threw it into the JSON parser to ensure it parsed correctly:
And it did:
This is the way! Hope it gets you where you need to go.
