Passing Body Content in Post Snap

So after you perform the steps as described in my previous post you do end up with a string that looks like that. Ending with ‘==’

Ok, so the account is overwriting the other Authorization header that you added in the Headers section of the snap.

But if one of the components of the Authorization header that you’re adding manually is a client secret that presumably you want to protect, how are you storing that securely? Don’t you have the same issue as with the password?

I have to confess that I am not sure how to handle this type of data my experience with SnapLogic is still in its infancy. Using postman to initially test I just use environment variables. Right now in SnapLogic, I am just handling it directly in a mapper snap. I haven’t really seen any documentation that discusses how to handle the various credentials you may need to store when consuming 3rd party APIs within the SnapLogic platform. I believe that an OAuth2.0 SnapLogic account would store this information, but I don’t think it would work overall because of the delivery expected on the RingCentral side, among other requirements for creating an OAuth2.0 account.

Any guidance you could provide would be much appreciated?

I see that you have the extension specified in postman, is that required for your particular instance? If not, you can just use the OAuth2 Account within the REST snap pack as it has a grant type of password that you can use. It seems the only missing item at that point would be the ability to get the endpoint_id back from the request, if that’s an important step, it might be worth looking into the authorization_code flow in their documentation as that seems to not require the additional parameters in the body of the password grant flow. Again, this can be achieved with the REST OAuth2 Account. It also looks like they provide an OpenAPI specification, so you could use the appropriate account type for the Open API Snap to potentially achieve the same thing, assuming you’re able to get it working in the REST OAuth2 Account

Thanks for your response. That entry is actually not selected. The extension can be concatenated to the username( a phone number in this case) and passed with the username at that point. That is what I am currently doing in that snapshot you see above.

I am trying to get an OAuth2 account working in this case. The app in Ring Central does not provide a redirect URL, which if I understand correctly, rules out the option of authorization_code flow. I am trying to get it to authorize using the password flow but I get an error string in a new tab. See below.

{“response_map”: {“error_list”: [{“message”: “Request from returned an error (response code: 400, response: {\n “error” : “invalid_client”,\n “errors” : [ {\n “errorCode” : “OAU-123”,\n “message” : “Client authentication is required”\n } ],\n “error_description” : “Client authentication is required”\n})”}]}, “http_status_code”: 500}

Do you know what I might be missing? Again please forgive my lack of knowledge in this area.

redirect_uri is what is provided for SnapLogic to respond, in this case, it would likely be (in the rest account) which redirects back to the base url for snaplogic to complete the next step of the auth. If you move to openAPI, you’ll replace rest with openapi. The REST OAuth2 Account documentation has it right at the top under Account Settings, it’s quite a bit confusing here because in this case you may not know what a POD is.

So if I understand you correctly, it sounds like there really should have been a place on the RingCentral side to add a redirect url? I did check several times because I expected there to be one as well, but never saw an option to enter a redirect url.

I added the redirect_uri argument to both the token and auth endpoint config sections using the uri you provided above.

When I click on the authorize button it looks like it is successful. A tab is temporarily opened and closed(it appears blank for its entire short duration on screen) and then the access token, refresh token, and Access token expiration are all populated. The first two are indicated to be encrypted and the expiration is a long numeric string.

However, when I go to validate the pipeline I get a long wait and then an error on the rest get snap which reads…

Failure: Error reading account, Reason: Snapi request failed: {“response_map”: {“error_list”: [{“message”: “Request from returned an error (response code: 400, response: {\n “error” : “unauthorized_client”,\n “errors” : [ {\n “errorCode” : “OAU-251”,\n “message” : “Unauthorized for this grant type”\n } ],\n “error_description” : “Unauthorized for this grant type”\n})”}]}, “http_status_code”: 500}

The only thing I can see is that it is possible that the client id and client secret are not being passed as expected by RingCentral (i.e. concatenated together as client_id+’*’+client_secret and then the whole thing is base64 encoded). Does this account type take care of that in the background, or is the issue something else entirely? I do see in the error that there is an “Unauthorized for this grant type”, but I am successfully using that grant type in Postman.


I created a RingCentral account yesterday, but haven’t been able to get a Sandbox account up and running. I did get to the point in the provision where login takes place and I can share some screenshots there, but here’s the screenshot of my account on the SnapLogic side (it’s a REST OAuth 2 Account)

On the RingCentral side, you’ll want to set your application to be a 3-legged application with redirect_uri being the previously mentioned uri ( ).

This will bring up a RingCentral login prompt for you to fill out with your (I believe) sandbox account, and then it should be able to get a token back from the token endpoint. Again, I haven’t been able to get a Sandbox account created through RingCentral, so I can’t validate this on my side.

Our OAuth2 Account will follow the Auth code flow semantics directly that they specify here. You’ll need to check the box at the bottom of the account that specifies Sending Client Data as Basic Auth header, that’s talked about in the “Step 3. Exchange auth code for access token” section. Once it authorizes properly, you’ll want to then check the box that says “Auto-refresh token” in our snap account configuration, as that will continually refresh the token behind the scenes so that you don’t have to perform the login screen piece any more.

I think I see what I need to do differently. On the RingCentral side, I don’t think I chose the 3-legged OAuth flow authorization code. So let me try to setup the way you have pointed out here. I am betting I will have to create a new app on the RingCentral side. I will get back with you on this post once I have done that.


When I was playing around, it seemed you could change auth type fairly easily, hope this works for you!

You mean on the RingCentral side right?

Yes you are right. It was easy to switch on the RingCentral side. Let me see if I can get it to work in SnapLogic now.

Okay some good news. I have made the changes and it looks like I am successfully authenticating with RingCentral. After doing so, I checked the box indicating to auto refresh the token, so that the authentication step does not have to be manually performed by a user. However, when I validate the pipeline I get a message back that says…

\n “errorCode” : “InsufficientPermissions”,\n “message” : “In order to call this API endpoint, application needs to have [EditAccounts] permission”,\n “errors” : [ {\n “errorCode” : “CMN-401”,\n “message” : “In order to call this API endpoint, application needs to have [EditAccounts] permission”,\n “permissionName” : “EditAccounts”\n } ],\n “permissionName” : “EditAccounts”\n}

This indicates that in the application on the RIngCentral side additional permissions are needed. I have to point out though that this call works perfectly in Postman with the current permissions and this particular permission of “EditAccounts” is not even an option in my app on the RingCentral side.

Do you happen to know what might be causing this particular message? Or what we need to look at next to get a successful call?

It appears to be an application permission issue, you can see those in the “Security” section below where you set your authentication, they have explanations for them all here but this is getting more into RingCentral-specific items, which I don’t have any real experience with, unfortunately.

Now that you have those items working, you MIGHT be able to get password auth working, I did some messing around with it, but again since I don’t have a working Sandbox Account, I can’t verify, that setup would be similar to this setup, but would require you to select “password” as your Grant type, in this case, I’m using a dummy phone number 555-555-5555, but for me even with my normal login credentials to the console, I don’t have it working and it seems to be due specifically to the account itself, not the application. The important piece here again is “Send Client Data as Basic Auth header” it’s what sends the client id and secret to the password endpoint within the header of the request. You’d have to go back to your old application for this to work and make sure you set the client id and secret appropriately for the request. This ONLY makes a call to the token endpoint, but I just used the same url for both the auth and token config.

For specific endpoints and permissions/scopes, you may need to look at that specific endpoint documentation to know specifically, but for instance, I don’t see “Edit Account” in my options, so my new account must not be set up well enough. for the Password setup. You might be able to add all available scopes from the “Security” section to your other setup to get it working fine, though.

Okay that is one difference (the fact that you use the token endpoint for both OAuth2 Endpoint and token fields) that I see you did that I had not done when I was trying to get the password grant type to work.

I have everything switched back over on the RIngCentral side. Do I still need to have the Auto-refresh token enabled on either side? Also do I need to click the authorize button when I edit the account and change back to password grant type (it doesn’t seem like I would need to click that button)?

Okay I get the same permissions error when switching back to a password grant type.

I have to stress that this does not happen when I follow the process in Postman, which leads me to believe that it is on the snapLogic side, or something between the data exchange specifically with the snapLogic post snap and RingCentral.

I also have to point out that this permission is not even an option in RingCentral. Finally the idea of just giving full permissions to the app in Ring Central is problematic, because in order to promote your app from the Sandbox to Production you have to test all permission scopes explicitly on top of meeting additional criteria before your app is eligible for promotion to production. So we really dont have the option of of giving a broad scope of permissions. Even if it did work, it leads to potential problems down the road.

Do we need to start looking at converting this thread into a ticket and escalating it?

Are you setting the scope within postman? if so, you can add it as an auth endpoint config with scope as the key and the items you have in scope as the value. For authorization_code, I believe you’ll need it in both the token and auth endpoint configuration, it’s worth having it in both for password authentication just in case, but again their documentation doesn’t specify the scope anywhere from what I had seen.

If this doesn’t work, or you’re not specifying the scope, I think escalating to a ticket might be beneficial.

No the permission scope is set in the application that you create on the RingCentral side and then you are provided with a client ID and secret for the application. Is there a way to convert this post to a ticket? There is a lot of relevant information here.

I think you could just link this thread in your ticket.