Wow - I’m surprised to hear that the burnt offering didn’t appease the programming gods!

I’m sorry that you’re having some trouble here though, and in truth I’m also a little confused by the UPS API documentation. Despite this, I think the missing detail here is the `scope` parameter that we can see included with the response.

Essentially, my hunch is that while you got a valid token, that token might not have any scope to access resources. Perhaps I’m reading it too literally - but it looks to me like the auth endpoint needs a `grant_type` property in the request body which specifically contains the string, “client_credentials”. Currently, it looks like your app is passing the integer 1 in this property.

Could you please give that a try with a new API connection?

I also wasn’t able to see where the `client_secret` is currently being included with the authentication request - could you please confirm whether this was removed during testing? To be fair, this page doesn’t list it as a requirement, but this page does - albeit somewhat ambiguously.

I’m sorry I can’t provide a concrete answer for you here, and if my suggestion above doesn’t help - I wonder whether we might be able to glean the specific API requirements from an example (hopefully) provided by UPS when using the yellow “Authorize” and “Try it out” buttons on the docs pages.

I’m curious to hear how it goes; best of luck!

Hi Christian,

Thanks for your detailed response.  I have made the changes you mentioned and am still getting the same result.  Now the only part I was confused about was you asked for a “new API connection”.  Are you suggesting I try a different kind of authentication other than Basic Auth?  Also, I am passing the access_token through the Computed Field, but I read somewhere (I can’t find the link now) that you can’t use these with Basic Auth?  If that’s the case, then I’ll have to try to get another Auth mechanism working, as I could only get Basic Auth to work with Zapier.  Thank you very much for your help!  I got all the other ones working, except UPS---so frustrating!

This is the post I was referring to about passing the values from the Auth to the actions:  

I just noticed above that I said I contacted FEDEX API support, and I meant the UPS support.

Hi @pesmonde !

It sounds like you’re able to get a token from the token/ endpoint, but when you try to get tracking details that’s when you get the error, is that right?

Questions:

1. Does Zapier give you an authentication? 
2. Have you tried the “Test Connection” button on that authentication to see if it works?
3. Is this problem happening with your UPS or UPS API app? (Or another?)

Things to try:

1. Take the token and do a “manual” API request via curl or postman or insomnia to see if that works

Hi @shalgrim, thanks for your reply.  Here’s the answers to your questions:

1. I can get authentication to work with Basic Auth, yes.
2. Yes, I have tested it and it works for that step.
3. This is happening on my custom API that I am developing on Zapier platform.  I can successfully test all of my keys/secrets through their interface--just not on zapier.

I have tested via Postman and it works, I think it is a Zapier issue--but since their support does not formally help with this, I am stuck in these forums for help.  @Christian W did answer a few initial questions, but I haven’t heard back from my above questions.  Thanks for your help!

Hey @pesmonde 

> This is happening on my custom API

I see five different apps in your developer account. One is named UPS. Another is named UPS API. What app are you working on here?

@shalgrim -- It is the regular UPS one.  I created the UPS API one as a test from the response from @Christian W   I cannot get the API one to work at all, but the regular one I can get the auth to work, but not the action.

Hm, so you’re able to get tracking details with Postman but not Zapier. The only way I can think to narrow down where things are going wrong is to compare all of the details between the two requests to see what’s different. This includes the request parameters and headers. We can help get all those details from our logs, except censored for secrets like Authorization, client_id, and client_secret, but of course you’d have the id and secret and can get the access token from testing…

Another potential avenue is to look through the results on this Google search for the error code being returned and see if any of them pertain to your situation.

I’ve confirmed with our platform support team that you’re more than welcome to reach out at the link I posted above and, while they of course can’t provide support on UPS’ API, they can help you compare the Postman to Zapier calls. But if you’d rather try to piece that together in this forum I can share any non-identifying information from the logs if you make some new calls (looks like all previous calls have rolled off of our logs).

Thanks for your reply @shalgrim.  I have had to move this project to the backburner for now.  I got USPS, DHL, and Fedex connections working with very little issue, and I’ve already spent more time getting UPS working than all the other ones combined.  Their support team has been moderately helpful, but is unfamiliar with Zapier.  It seems crazy to me that none of the big shippers would want to have native Zapier connections and instead rely on these 3rd party systems to act at the go-between.  All of them have monthly fees attached for even basic services like tracking.  I appreciate your help and wish there was more UPS could do to facilitate this.

Thanks for letting us know! And reach out again if you decide you want to pick it up again