Help porting over from Postman to Workato

[rharkness]

Using Postman, I have successfully retrived a bearer token and connected to the endpoints provided to me by the client.  
I am not having success taking this functioning logic and recreating it in Workato using the HTTP connector.
What I'm not sure about is whether or not my issue is that the client is using a username/password to authenticate the token endpoint and it appears in order to use a bearer token I must use one of the OATH HTTP options

Anyone have any luck retrieving a bearer token with just an username and password?
This may or may not matter, but the endpoints I'm connecting to require the token to be passed in the header

[gary1]

Excellent.

About the sensitive data...

As far as I know, Workato doesn't support HTTP connection types that use POST calls. Seems odd to me, but I've just never found a way around it.

If your client API documentation says it must be a POST with form-encoded data, then it is what it is. As an alternative, you can try to send a GET with url-encoded data. If that works, then you can make a new connection.

If this fails, the only "safe" way I know to obscure the password is to do this:

• Make an environment property or a project property for the key
• Use that property data pill as the password in the recipe
• Right click the HTTP action and click "Mask data"

This will keep the password out of the recipe builder and out of the logs, but it will be accessible to anyone with permissions to view the properties.

Anyway, next steps:

1. Configure the response body to parse the token into a data pill
2. Create another HTTP action (you can probably re-use the "no auth" connection)
3. Pass the token data pill into the action
4. Profit

Let me know if you get stuck.

[rharkness]

Success!  Using 2 different HTTP actions I was able to get the token and then use the token to bring back data from the endpoint!

I'll play around and see if there is any way to do this more secure, but considering the client I'm working for is using the embedded version of Workato, I don't have access to create environment properties or project properties
In the meantime, I have a functioning way to pull the data back so I can start writing my recipe.  I'm already behind schedule because of not being able to figure out this HTTP Connection and Action thing! 
I can now give a more favorable status report tomorrow

[Bhagya_pola]

Hi @rharkness 

Here's what I suggest:

If your token expires in a short time (like an hour or less), it's perfectly fine to have two HTTP requests one after the other in your recipe. The first gets the token, and the second uses the token (via the datapill) to call your endpoint. Doing it this way helps avoid Workato's sensitive data warning.

However, if your token is valid for a longer period, it’s better to store it in a Project Property (append secret to the name of the project property while defining) and use that in your HTTP requests. You can even automate updating the token using Workato’s Developer APIs. For example:

• Set a scheduler based on your token’s expiry time

• Use an HTTP request to fetch the token

• Then update the Project Property using the Developer API

This approach keeps things secure and efficient

[gary1]

I don't think the problem is with obfuscating the token, but with the creds used the get the token.

The endpoint to get the token is a POST, and there's no way (as far as I know) to make a POST call as part of an HTTP connection (not action, obviously). The SDK offers more flexibility with authorization, but the HTTP connections are GET only with headers or URL params. This means the credentials need to be added directly to the HTTP POST action to get the token. 

As for tokens.... I always call to get a new token and just let it live in the recipe. There are probably APIs out there that rate limit token requests, but I've never encountered one. Some may call this criminal, but the 🚨 API Police 🚨 haven't caught me yet! 

[Bhagya_pola]

Yes @gary1 , you're right! I'm actually working on a similar setup where I had to make a POST call and pass the creds as form data.

For now, I’ve hardcoded the credentials directly into the HTTP action (I know I know - Bad Practice 😅), but interestingly, I didn’t get any sensitive data warning there. The warning only showed up when I passed the token in the headers of the next HTTP step.

That’s why I suggested that workaround—it seemed cleaner in that context.
Also, my token expires every hour, so I’m dealing with that fun little expiry window too.

And hey, glad to hear the API Police haven’t caught up to you yet 🚓😂