topic Re: Help porting over from Postman to Workato in Workato Pros Discussion Board

Help porting over from Postman to Workato

rharkness — Thu, 24 Jul 2025 22:06:12 GMT

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

Re: Help porting over from Postman to Workato

gary1 — Thu, 24 Jul 2025 22:21:20 GMT

I've been down this road more times than I could count and it can really be a struggle. The good news is I've always been able to find a way to authenticate using the HTTP connector, it just takes a lot of testing and a little voodoo to land on the right config.

A lot of times OAuth is implemented incorrectly on the client side, so using standard OAuth doesn't work and you need to be creative with Workato's custom auth options, or (eek) go with no auth on the connection and authenticate directly in the body of the call itself.

I can't offer much more direct help without getting more information about what the endpoint is expecting, but if you can provide some details I'll try.

It would be great if Workato could support a cURL import like Postman.

Re: Help porting over from Postman to Workato

rharkness — Thu, 24 Jul 2025 22:42:37 GMT

I'm not afraid to admit this stuff is not my area of expertise. I'm an old school C++ / Java developer haha
I have two of these HTTP connectors I have to get working. One uses a username / password to authenticate to hit the token endpoint and another that uses OATH2.0
The one with the username/password I am at a loss to get working

The other one I get a "HTTP OAuth connection is no longer valid" error message when I try to run my stop hitting the data endpoint

I was trying to figure out how to do the authenticate directly in the body of the call, but I cannot figure out that syntax since I'm not able to find a way to export out the body from Postman in JSON since it's configured as x-www-form-urlencoded

I appologize if I'm not giving the right info. I'm learning as I go here

Re: Help porting over from Postman to Workato

gary1 — Thu, 24 Jul 2025 22:55:00 GMT

I'm a pastry chef but we'll figure this out.

Based on what you're saying, try this:

Make a new HTTP action
Make a new connection and select "None" as the authentication type
In the HTTP action, click "set up manually" at the bottom
Set the Method to POST
Set the Request Content Type to URL Encoded Form
Expand Request Body
Click Add Form Data

This will imitate how form-encoded data is entered in Postman, so now you should just have to copy it over.

You should also set the Response Content Type correctly. I'm guessing it's a JSON response, but you know best here.

It's probably easiest to test this in an isolated recipe first.

Once you get this far, let me know if it runs or crashes. If it crashes, what's the error message?

Re: Help porting over from Postman to Workato

rharkness — Thu, 24 Jul 2025 23:13:42 GMT

OK! Progress. Following your steps I was able to create an HTTP request to retrieve the bearer token.

Is my assumption correct that my recipe will need to have a HTTP request to get the token, then another HTTP request to hit the endpoint passing that token?

Workato did give me a warning that it is detecting sensitive information, but I'm not sure how else to make this work without doing it this way 😞

Re: Help porting over from Postman to Workato

gary1 — Thu, 24 Jul 2025 23:29:28 GMT

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:

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

Let me know if you get stuck.

Re: Help porting over from Postman to Workato

rharkness — Fri, 25 Jul 2025 00:09:54 GMT

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

Re: Help porting over from Postman to Workato

Bhagya_pola — Fri, 25 Jul 2025 03:09:22 GMT

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

Re: Help porting over from Postman to Workato

gary1 — Fri, 25 Jul 2025 04:39:22 GMT

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!

Re: Help porting over from Postman to Workato

rajeshjanapati — Fri, 25 Jul 2025 06:11:24 GMT

Hi @rharkness @gary1

When dealing with sensitive information, we have another approach where the value is not stored in Properties, Lookup Tables, or anywhere else. Instead, it's generated dynamically within the flow whenever it expires.

Please refer to the image below — in place of the Python connector, you can use the HTTP connector. Pay close attention to the step comments for better understanding. Also, make sure to store the access token in a variable so it can be reused in the following steps of the recipe.

Hope this makes sense! If not, feel free to reach out for further discussion.

Re: Help porting over from Postman to Workato

Bhagya_pola — Fri, 25 Jul 2025 06:38:55 GMT

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 🚓😂

Re: Help porting over from Postman to Workato

mppowe — Fri, 25 Jul 2025 14:13:00 GMT

I'll add one thought to this thread, b/c I, too, have struggled with this problem in the past. I've also had to put credentials in a POST body and not been thrilled about it. But one extra thing you can add to fend off the API Police is to make a new Project meant to store secured assets. For example, we have a Project called "Recruitment and Admissions", then I made one called "Recruitment and Admissions - Secured". That's the project I stash recipes like this where I have to expose credentials, and then not everyone is given access to that project. All the other stuff already mentioned still apply, as far as data masking and such, but at least this way there's some RBAC around the sensitive credentials among the developers.

And @gary1 , you're not a pastry chef, it says you're a Star Chef 😁

Re: Help porting over from Postman to Workato

mppowe — Fri, 25 Jul 2025 14:14:38 GMT

You should totally make an idea for that, if one doesn't exist. I'd vote for it in a heartbeat

Re: Help porting over from Postman to Workato

shivakumara — Fri, 25 Jul 2025 14:23:05 GMT

Hi @rharkness ,

Here's my recommendation for securely handling bearer token authentication using the HTTP connector in Workato:

Recommended Approach

Create an HTTP Connection with Username & Password Authentication
Use Workato's HTTP connector to create a connection that securely stores and uses your username/password credentials.
This avoids hardcoding or exposing credentials in recipes.
This connection can then be reused across multiple actions/recipes.
Use the HTTP Connection in Your Recipes
When using this connection in your recipe actions, the connector will handle the authentication step using the stored credentials.
If your Bearer token has an expiration (e.g., 3600 seconds), you can build a logic check before any critical API call to ensure the token is valid.
Separate Token Generation from Business Logic
It's a best practice to modularize your logic:
Use a separate function or step early in the recipe to check token validity and regenerate if needed.
Keep your token generation and API data actions decoupled for easier debugging, better reusability, and improved maintainability.

Thanks and Regards,
Shivakumara K A

Re: Help porting over from Postman to Workato

rharkness — Fri, 25 Jul 2025 19:47:34 GMT

My token appears to expire in 24hrs but I'm using Workato in an embedded environment which is not configured to allow me accerss to create or modify Project properties