Passing Body Content in Post Snap

Hi,

This is a very novice question, but I am having trouble with a post request snap. This is just to authenticate with the RingCentral platform to receive a token for API consumption. I am able to successfully retrieve an access token when calling the oauth/token endpoint in Postman. The issue arises when I try to move this post call into SnapLogic. The call requires certain parameters to be passed through the body and I am not sure how to duplicate this in SnapLogic post snap. Please see the screenshot of the Postman call Body tab below.

I have created a basic account in SnapLogic to store the username and password and my post snap references that account. I am also aware that the credentials of a basic account can be accessed using the “Account.Username” and Account.Password" of the respective referenced account within the snap.

I am just not sure how to build out the body section in the “x-www-form-urlencoded” format as shown in the screenshot? The error I get back when validating this post snap is just a 400: Bad Request.

Any insight/help that anyone could provide would be greatly appreciated. Please let me know if additional information is needed to provide assistance.

Thanks,
James

Hi @jsmith141 ,

When the content type is x-www-form-urlencoded then the format of the body should be the same as the query string:

parameter1=value1&parameter2=value2

In SnapLogic you can send the request body in the HTTP entity field of the REST Post snap.
Example expression:

“param1=”+encodeURIComponent($param1)+"&param2="+encodeURIComponent($param2)

Best Regards,
Dragan Talevski

3 Likes

I am also aware that the credentials of a basic account can be accessed using the “Account.Username” and Account.Password" of the respective referenced account within the snap.

I’m not sure what you mean by that. I’m not aware of any way to reference account fields through expressions in the snap.

Here’s a simple example with no account where the credentials come from the input document.
REST Post Echo Form URL Encoded_2022_03_09.slp (4.8 KB)

Hi Ptaylor,

Thanks for your reply. please note that these containers should be all lowercase, “account.username” not “Account.Username”. This was a feature that I came across in the community. This is not the exact article that first came across this feature, but it references the same containers. Perhaps it is not available for all account types, or maybe it is in the process of being deprecated?

1 Like

Hi Dragan,

Thank you for your reply. I have implemented the encodeURIComponent call as you describe but I am getting the same 400 error. Please see the exact line below…

“grant_type=”+encodeURIComponent(“password”)+"&username="+encodeURIComponent(account.username)+"&password="+encodeURIComponent(account.password)

I have the Upload body type fields set to “Multipart form-data”. Does this need to be changed, or is there another setting on this snap that may need to be adjusted?

Thanks,
James

encodeURIComponent(“password”) is just password (there’s nothing that needs to be encoded), so you could simplify that to just "grant_type=password&username=" + ...

But I still don’t understand how you’re able to get account.username and account.password to resolve.

Upload body type isn’t used here. But you do need to add a row to the “HTTP header” table with Content-Type application/x-www-form-urlencoded, as I showed in the screenshot from my last reply.

Ah! I just looked at that other Community post you linked. I wasn’t aware of that hack. But I’m pretty sure it only works in an expression used in the Value column of the HTTP Headers table, not anywhere else. I don’t think you’ll be able to use it for the request body.

Oh I apologize for the confusion, I already had that specific header in place We are successfully using the account.username and account.password in another pipeline i.e. in the HTTP entity field of the POST snap.

Wow! You’re right. I guess I hadn’t tried it with exactly the right syntax. This expression works just fine in the HTTP Entity field:

"grant_type=password&username=" + account.username +"&password=" + encodeURIComponent(account.password)

Oh yeah the statement itself validates, but I am still getting a 400 bad request error

Let’s see a screenshot of your REST Post snap settings.

@jsmith141 You can try removing the account from the REST Post snap and send the account username and password through pipelines parameters to check if it’s working.

2 Likes

I think we can, but first I want to ask, would passing the credentials as pipeline parameters expose them to be intercepted by unwanted parties?

We went ahead and tried it, since it is a sandbox account and it worked, but where do we go from here?

I think I missed something. Why move the credentials to pipeline parameters when you can just use account.username and account.password?

I’m wondering the same thing. I also wonder if maybe I just need to delete that account and recreate it?

Are you saying that you got it working by removing the account from the snap and replacing account.username and account.password with pipeline parameters in your HTTP Entity expression?

If that’s the case, it means the server is rejecting the request because of the Authorization header added by the account. So that does leave you in a tough spot, since the only way to keep the password secure is by using an account.

Let’s test that theory: Add an Authorization header to the version that works, to see if it breaks.

The Authorization header added by the Basic Auth account would have a value like

Basic bXl1c2VyOm15cCZzc3cwcmQ=

Yes that is what happened. There is a missing piece that you don’t know about yet. Basically there is already an Authorization header that is required by RingCentral. Basically you have to take an app id and client secret concatenate the two the base64 encode the concatenated string and pass that as your Authorization header. Didn’t mean to leave that out earlier. Just didn’t realize it would be relevant until now.