I have a couple workflows I am currently building and they all keep failing any time I use the HTTP Request Action. I downloaded the workflow execution history and this is the error I’m receiving :
I assume the way I set up the HTTP Request authentication is incorrect, and was wondering if anyone else has ran into this issue and solved it? Below is the HTTP Request action and the data I’ve inputted.
For some additional context, I tried running the API from the SailPoint Developer Community page and it works fine. I got a 200 response and the campaign was created in our tenant. I used the Generate Bearer Token API, plugged in the access token and the API worked with no issue. This leads me to believe there’s something wrong with my HTTP Request step that isn’t allowing it to grab the access token. Any help would be much appreciated!
This is just a test workflow I built to get the HTTP Request configuration down. When I first started with workflows, the Create Campaign action did not have the ability to set the reviewer as a Governance Group, which made me look into the HTTP Request action. As of recent, SailPoint added an input field to set Governance Groups as reviewers in the Create Certification action, so we are using the Create Campaign action for any workflows that create campaigns. But now, I am at the point where I need to start using the HTTP Request for other workflows I am building, and this test workflow is just something I built to play around with and verify that the HTTP Request is configured properly.
@colin_mckibben I gave the IP’s to one of our security engineers, they said there wasn’t any traffic and that they would look into it, but they don’t believe this is the fix as of now. Are there any known issues on your end regarding the authentication problems I’ve been running into? I’m pushing them to just whitelist the IP’s just so I can test and know for a fact that the allow list isn’t the fix.
If this were an issue with your user level, scopes, you would have gotten a 403 instead of a 401. If the IP allow list doesn’t fix this, then this leads me to believe that the configuration is incorrect or this particular workflow is in a bad state and can’t properly retrieve the secrets from the secret manager. Have you tried creating a brand new workflow and configuring a new HTTP request from scratch?