Workflow HTTP Request Not Creating Campaign

Hello,

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!

Hi @mosareini,

Just for remark, why you do note use native Create Certification Campaign action ?

image

It’s simple than http request.

Best regards

For your error, check client id and client secret authorization.

Do you use personal access token (PAT) ? it’s mandatory to use that.

As you say : “I used the Generate Bearer Token API” make sure to generate personal access token here : Managing API Keys and Tokens - SailPoint Identity Services

hey @mosareini Be sure that the user has ORG_ADMIN some apis only allow this access.

Hi @baoussoundam,

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.

1 Like

Hi @ipobeidi,

I have Admin user level and for the PAT I selected scopes: all

Yes, I use the PAT for the ID and Secret. I selected scopes:all as well, and I am still running into this issue.

1 Like

It should be work with PAT. Change Credential location to Body or clear it and test again

Hi @mosareini,

There was a recent thread where the issue was resolved after whitelisting the IP’s. You may want to take a look into that as well.

1 Like

Oh wow, I’ll definitely look into this and report back if it works, thanks Jesvin!

Can we please have the relevant documentation updated so that others do not need to figure this out by trial and error?

@mosareini did the IP allow list work for you?

@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?

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.