Passing credentials in JSON body to authorization endpoint

Some services I am working with require a REST Post to an authorization endpoint obtain a session token to be used in the header in subsequent REST calls. The authorization endpoint requires the account credentials to be passed in a JSON object in the request body.

This can be accomplished easily enough in SnapLogic by using a JSON Generator and a REST Post Snap.

2020-10-02 13_51_36-SnapLogic Designer - Export Informatica Activity Log - _TWUDev_projects_Jacob Er

2020-10-02 13_52_14-SnapLogic Designer - Export Informatica Activity Log - _TWUDev_projects_Jacob Er

However, this is not ideal from a security or account management perspective because the account credentials are stored directly in the pipeline in plain text and not as an account object.

Is there a better way to store credentials and use them in a pipeline for services that use this kind of authentication pattern?

Hi @jervin

You can try with REST Basic Auth Account.

In the REST Post snap(Account Tab) you should select the created auth account:


Spiro Taleski



@Spiro_Taleski , @jervin

I have the similar request. Need your help in how to refer the SnapLogic Account in Rest POST API call. As of now we are passing via Pipeline properties. I want to substitute the credentials from Rest Basic Auth Account.

Community Post:

Current Pipeline Setting:

@jervin @Spiro_Taleski @kamalaker.pinna Actually this is possible but this is somewhat of an undocumented feature that does not have finished integration with our UI - however I will describe how this can be done with the REST Snap Pack’s Basic Auth and OAuth accounts.

The REST Snaps (POST/GET etc) are able to reference the account configured on the Snap through a special account variable, account.

This is different that how standard variables are referenced; per-document variables that come from an input document have the "$" prefix (e.g. $someField, whose value can be different for each input document to the Snap) and pipeline variables, called Pipeline Parameters, that are static for the pipeline execution lifecycle and denoted with the underscore prefix (e.g. _someParameter).

However, if a field is expression-enabled and uses a value of account in the REST Snap Pack, a reference to the account (if compatible) can make some fields from that account accessible to the Snap configuration.

Unfortunately our UI integration here is incomplete here for Basic Auth and it will generate a UI error, but the account data binding will actually work correctly.

So for a Basic Auth account, you could do the following:

The account.username and account.password account variables will bound to their respective values and then sent as part of the HTTP request body.

For OAuth 2.0 accounts, the only account variable field available is account.access_token (which is mentioned on the documentation) - this gives access to the OAuth access token.

It may be possible to use this technique to simplify and secure your solution, but it does have some downsides in terms of our product interface experience plus the complications that can arise when the Snap attempts to use the account credentials in the way it expects in addition to the customizations made to the request by the user.

Perhaps you can try this out and let me know your feedback please.



Thanks a lot for making me understand in detail of different approaches.
I tried account.username & account.passowrd in my API call but it errored out with below

“{\r\n “errorCode”: “AUTHORIZATION_INVALID_TOKEN”,\r\n “message”: “The access token provided is expired, revoked or malformed.”\r\n}”

Below snapshot is how my API call looks like.

The same API call works fine when i pass through pipeline properties like below

‘{“Username”:"’+_SecretName+’",“Password”:"’+_SecretText+’",“IntegratorKey”: “’+_SenderIntegratorKey+’”}’

Please let me know if I am doing anything wrong here.


Please read account.passowrd as account.password.

@kamalaker.pinna I think you need to click the ‘=’ button to enable the expression.

Thanks @Jervin, API call is failing even after changing the expression but this time i am able to see the credentials substituted from the account ref functions.

Whole point to refer account is to access the encrypted password in a secure way but when the pipeline fails SnapLogic is publishing the credentials (Clear Text password’s) in the error log which is again a security concern for us.

Is there any other way?


@kamalaker.pinna yes, I hinted at this wrinkle in my last post - my concern is leveraging a Basic Auth account (that is what you are using, correct?) to use for non-Basic Auth authentication will result in a “Authorization” header still being added to the request and the Docusign API complaining about that.

(Perhaps you could confirm by adding an Authorization header in Postman with a “Basic XYZ” random value and observing whether the API complains in the same way. If so, does it do the same if the Authorization header value is empty?).

However, I see you are using the Legacy Authentication mode with DocuSign. I just tried to do the same but it seems that that auth mode is no longer officially supported with REST API v2.1.

I did set up an OAuth flow with DocuSign and was able to successfully authenticate and retrieve account data with the REST GET and REST OAuth 2.0 Snap Account - would you like me to document how to do that?

@robin, Yes i am using REST Basic Auth Account.
Please help with the document.

I tried from Postman with Basic Auth and i get the same exception



"message": "The access token provided is expired, revoked or malformed."


@kamalaker.pinna I wrote up a walkthrough of using OAuth with the REST Snap Pack to interact with the DocuSign API: Tutorial: Using the DocuSign eSignature REST API with the REST Snap Pack and OAuth 2.0

Hi @robin

I have the same requirement. I have gone through your post using account.username and password in http entity proiperty… But my request does not expect Authorization header. In this case how can I encrypt my credentials?
Example request for my endpoint -

POST /authenticate HTTP/1.1
Content-Type: application/json
Content-Length: 58

    "username": "username",
    "password": "password"