My org has had an API trigger for our dispatcher, that recently started returning a 401: unauthorized. I believe there was a client id / secret, which we would then use to get a bearer token, and the bearer token was used to call the API. The first API call using the client/secret still successfully returned a bearer token, but the call with the bearer token returns the 401 unauthed. This stopped working on Sept 1st; I believe the functionality may have been depricated. Is there a way to fix this functionality so that it works the way we had it? I understand we can use a PAT, but our goal is to not hard-code the bearer in the API call.
HI @dsnell,
You can check this with API team,
Try to make two API calls in Post man or SoapUI, check and understand that if the issue is occurring in these apps as well, then it must with respect to API end, share the Json error response and error code with API team. Asked them to check the validity period for a token.
Hi @dsnell
If you don’t want to go with PAT, you can consider creating external application (confidential) in automation cloud, add required application scopes to the same, retrieve client id and secret and use the same to get your access token.
May I know what kind of trigger is this
ideally a start job api would have sufficed here
cheers