Hi Experts,
Third party app admin has provided me API to call along the bearer token to authorize.
Kindly suggest if Appian can use such bearer token Authorize the API calls or not if yes then can we use it in our connected system or not, for now I have used it directly in the integration object as header but its not working.
While using below Request payload in Appian Integration object its not being read properly because of the [ ] brackets.
{ "advanced_search": { "condition_rules_attributes": [ { "type": "ProfileTypeRule", "comparison_operator": "==", "value": "some vale" }, { "type": "ProfileStatusRule", "comparison_operator": "==", "value": "Active" }, { "type": "ProfileAttributeRule", "condition_object_id": "some value", "object_type": "NeAttribute", "comparison_operator": "==", "value": "some value" } ] } }
Discussion posts and replies are publicly visible
For that JSON like structure, I highly suggest to use the correct Appian dictionary syntax. Appian will then turn it into JSON automatically.
GauravSingh said:Kindly suggest if Appian can use such bearer token Authorize the API calls or not if yes then can we use it in our connected system or not, for now I have used it directly in the integration object as header but its not working.
Sure, Appian does support Bearer authentication. Just check the docs. What exactly does "not working" mean?
Hi Stefan,
Thank you for your response,
I was trying to use the bearer token in the connected system which seems to be impossible hence I have configured the Integration object to have Authentication as "NONE" and configured the token in the Header section of the integration object as in below screen shots.
I was trying to put the exact Json in the body which was throwing error. After converting the JSON to Dictionary and using a!toJson on it has resolved the issue.
Why did you not configure authentication in the CS? That's exactly the right place to do this! I frequently just but the string made of "Bearer + key" into the CS. But I learned that I sometimes had a leading or trailing space in that string, which broke it.
When you create an Appian dictionary in the body section, Appian will automatically turn it into JSON. There is no need for an additional a!toJson call.
Stefan Helzle said:Why did you not configure authentication in the CS? That's exactly the right place to do this! I frequently just but the string made of "Bearer + key" into the CS.
In the case of the thing I'm trying to build now, I'm not sure this setup will work (though i'd love to be wrong here), as the bearer token is accessed by a call utilizing client id/secret AND username/password, and expires after 24 hours. The added kicker is the target system (guardian) requires the credentials to be sent over ONLY via "url encoded" format (no other formats will even remotely work), so that seems to completely break the autiomated oauth/connected system approach too. So we're stuck manually constructing the call using a cobbled-together url string and figuring out somewhere to store the daily authentication tokens, and refresh them (presumably by some daily process) all by manual construction.
Yes, I implemented something similar in the past. Just wanted to point out that skipping auth in the CS for no reason might be a bad idea to start with.
What should the authentication option that we must select to configure in the CS?
Earlier I thought of using the API key once where Header Name I have put as "Authorization" and in the Value I used "Bearer 'Tokenvalue' " , but unfortunately it didn't worked.
The token that has been shared is a non-expiring once.
That's the correct way. As I describer above, I had an issue with some additional spaces, coming from copy&paste actions. Once cleaned up, the syntax "Bearer jasfz793qgfuaigfu99393" with exactly a single space works.
Ironically I was just working on this issue yesterday and at least for my system, found the correct syntax is passing the header name "Authorization" and value "Bearer *******" where *** = the token string itself (no quotes or single quotes or anything in the evaluated string of course).
This might vary by system though - for instance, the "bullhorn" personnel system requires the header name to be "BhRestToken" and the token is passed in plainly. Other systems might have different configurations that override the normal default, AFAIK.