disengaged
commented
9 years ago I initially thought the same as you regarding this issue, because as you say, the client id and secret are always sent (except for the methods where the access token is required in the call). However, my testing shows that the access token is used by the Untappd API, and my requests are treated as authenticated when sending the access token in the options. Maybe something changed over at Untappd, or maybe the request count is not counted correctly, I have not tested this. Regarding that, note that from what I've understood, Untappd also caps each authenticated user to 100 requests/hour, maybe that is also happening in your case?
The official doc from Untappd says the API can receive either client_id and secret or a users's access_token (example: https://untappd.com/api/docs#beerinfo). When you set client_id and client_secret in the configure block, those parameters are always sent, even if you pass in the option the "access_token" parameter. Code example:
options = Hash.new options["access_token"] = "something here" ... Untappd::Beer.info(beer.bid, options)
The thing is, that when client_id is sent, the Untappd API ignores the access_token, and the request belongs to the app (using the relation from the app and the client_id). I noticed it because my application reached too quickly the rate limit form Untappd API (100 requests/hour), and the requests should be related to each of the users who have connected to my app in Untappd.
I think that there should be a way that the gem checks if the options has a "access_token"; if so, the client_id and client_secret is not sent. Does it make any sense to you?