Flow Action, REST step, Issue adding Credential

[Jamsta1912]

Hi all,

I'm trying to create a flow action to make an API call.

I have created a credential record (API Key), a connection record, and an alias.

I'm using the connection alias in my REST step, and I'm using the data pill to add the credential value to the header:

 

When I test the step, I get an error: code: 401 - Invalid username/password combo.

If I paste the API token directly into the value for the token header (in lieu of the Credential value data pill) the API call is made successfully.

And here's the thing: when I look at the Request headers in the outbound HTTP log, I can see that ServiceNow is adding the text 'authorization=' in front of the actual API key, and it's leaving the 'token' header without a value:

 

So I can make this work, by simply pasting the API key directly into the value for the token header, but I would like to avoid having to do this, and would prefer to follow best practice using the connection alias.

Any thoughts on this issue?

Thanks

[Jeremy Duncan]

Want to check this out and see if it works for you? https://www.servicenow.com/community/developer-forum/how-to-access-api-key-credential-in-flow-design...

[Jamsta1912]

Hi Jeremy,

Thanks for your reply. That is the methodology I was using but I still had the strangeness with the headers. In the end I reached out to ServiceNow support. It seems like a peculiar bug with the instance I'm working on (neither I nor support could replicate the issue in a PDI). In the end they suggested using a Lookup Record step as a workaround, to get the credential record itself rather than the alias. I am happy with that - not much effort and it still avoids having to paste in the API key directly into the action.👍

[Alex153]

Hi, can you please share how did you configure Lookup Record step as a workaround?
Thanks.

[Jamsta1912]

Hi Alex,

Yes, the first step is to use 'Lookup record' against the 'API Key Credentials' table, like so:

Notice that the 'API Key' field is then available in the datapicker.

Then, in the REST step, I was able add the API Key as the value to the 'token' header:

So, this workaround is secure and still as easily maintainable as using a connection alias, as the actual value of the API Key is still abstracted away from the flow itself.