When using GET and POST node, the Request Headers is very useful, as it allows to build the header using different parts of Credentials.
I wish that was also available to the Request Body feature. Right now, we are dealing with many APIs that require us to authenticate using a custom request body. Most of the time, it uses information from the credentials in ways that are now usable with the current setup (get from a column or write it as text).
Hi Toscano
Maybe I’m not understanding correctly but you can make the Request Body variable by creating it using one of the many JSON parsing nodes and passing it as a flow variable or part of the table structure already.
If you’re wanting to change the Header setting for the Accept you can also make that variable, and could customize the headers → in the dropdown just choose and existing template or create your own.
Regards,
Wali Khan
Hi Wali Khan,
Thanks for your response. Let me rephrase what I wrote for the case I was not clear.
The main point is the ability to use credential information in the Request Body of the POST node. As far as I could tell, all the options (e.g. using JSON parsing nodes) does not allow me to use credentials information (which I can understand why). The only option in which I saw that possibility was in the Request Headers (as an example of what I whish was present in the Request Body).
Ahh okay maybe I understand now. To clarify a bit further →
Are you hoping that each parameter of the Request body could be a dropdown?
You can pass the credentials you have in a request body by typing them in to a JSON file and reading that it, but it sounds like you’re using SSO and therefore getting a token back as authentication.
Most applications give a mechanism to bypass manually logging in and getting a token via SSO for scenarios like this, and I would recommend that you work with the application administrator on getting an automated solution.
Are you hoping that each parameter of the Request body could be a dropdown?
Yes, exactly! Because it allows me to use credentials information that I capture from the user in a more flexible way.
I am not sure about the SSO part, but let me give more description about what I am doing:
I get the credentials used by the consumer (to run in the server). I need the username and password to build a POST body to an internal service, which involves:
username → username@email.com (string manipulation on Extract Context Properties)
password → password
client_id → constant value
client_secret → constant value
I don’t think the JSON solution would work with this as I need split and manipulate information coming from the Credentials Configuration, am I right?
Ah I see. I don’t think what you’re asking for would get implemented as the password would then have to be visible in plain text at some point.
If your service really does ask for the password in the body of a POST request instead of an authentication field that would be outside of the REST standards.
If you already have a client_id and client_secret, and are sending the username and password it sounds like you are authenticating against SSO and would recommend working with the SSO team to setup an application ID and password that allows for automation and impersonation .
