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...
Forum Discussion
Happy that we could resolve things, the OAuth2 Accounts are a little complex because there’s so much to them, but they’re very powerful with more and more services.
I still strongly suggest looking into the OpenAPI Snap if you’re going to be doing a lot of calls through RingCentral and are trying to do some investigating. There’s a link to the swagger specification which is OpenAPI compatible at the top of this page and you can simply use that OpenAPI snap and it provides suggestions for the paths within the spec in place with the methods that you need. You’d just have to update your redirect URI if you use authorization_code for the Open API OAuth account (ending in openapi rather than rest).
Sorry for the delay in response. Would the OpenAPI snap help us avoid some of the 401 errors I am still seeing on the RingCentral app analytic side? In order for an app to be promoted into production it has to have a <5% 4XX return code on all used end points for that app. I have this pipeline set to run every hour, but it looks like the call frequently fails with a 401, but then it retries and is successful, as best as I can tell.
Please let me know if this needs to be a different thread. I just noticed this morning that we are not meeting this last requirement.
Thanks,
James
I would assume your 401 errors have corresponding failed pipeline runs, if that’s the case, you might be able to investigate the specific causes of those, but I don’t think OpenAPI vs. Rest would really help you there.
You could set the snap retry policy to include auth errors in addition to connection errors, but it all depends what the actual 401 error is that’s coming back, and there should be respective failed pipelines that might help to figure out the specific conditions that are failing.
that’s the thing. I don’t see any corresponding failed pipeline runs? Is there something I need to change to get it monitor at a “lower level”?
Because I chose password for the grant_type, I did not check the auto refresh token option. Could that be the reason I see 401 errors on the RingCentral side? It looks like the it retries 3 times on the SnapLogic side. So could it be the 401 is being thrown because it tries to use the token it already has, but it is expired, so then requests a new token and all we see on the SnapLogic side is a successful run because after getting a new token on the 2nd try, everything works.
you should have auto refresh enabled, it should still work with the password grant. You should still be getting a refresh token back from the request, you can confirm it with the account edit view, it should have
Value is encryptedfor the “Refresh token” like the below screenshot
Okay I enabled that yesterday afternoon. So far on the Ring Central side, the 401 errors have diminished. In fact today(03/18) there is a 100% success rate running that pipeline every 59 minutes.
This may be an obvious question and I think I know the answer, but just for clarification, with the auto refresh enabled does that enable a background process to run on the account to refresh the token at the needed interval to prevent the account from having an expired token (independent of the state of a specific pipeline that may utilize that account)?
yes, the process looks for all OAuth accounts that are nearing expiration or expired, with a valid refresh token and does the authentication token refresh. It does periodic checking and looks for tokens that will expire before the next check of expired tokens and will refresh all of those tokens accordingly. In the case of your situation, if it doesn’t refresh for 7 days (which is the max life of a refresh token) it would then have to start from the initial password token request.
