I am having a heck of a time attempting to access the wallet that the user selects to allow my application access, and would like some assistance here in tracking this down.
Specifically, the user provides wallet/account access here:
However, it is not very clear where this is stored and/or available to my application to retrieve this data.
There is the list accounts call but that appears to list all 143 accounts available to the user (using wallet:accounts:read permission). It is unclear how to display only the account selected above (it appears primaryset to true on every account).
I also attempted to use wallet:user:read permission as outlined here, but the data that is returned in no way reflects a wallet that is selected via the above screenshot.
Any guidance/suggestions here would be greatly appreciated.
Hello @Mike-E! Thank you for taking an interest in trying out Coinbase APIs. For the details regarding your concern, we will check on this for you with our team. We will get back to you once we have more information. Keep in touch!
Hello @Mike-E. Thank you so much for reaching out. With regards to your concern, you can use the List Accounts endpoint. It is able to retrieve both wallets that are authorized and not authorized, but you can identify the wallet authorized by the user by looking at the first data returned.
Ah! That makes sense, @LaRisa. Thank you very much for the pointer. Is this mentioned in the documentation anywhere, by chance? This seems like a very obvious piece of information that should be mentioned somewhere to keep unnecessary inquiries from finding their way here.
The other issue I am running into is that of permissions. The user is explicitly assigning access to a wallet, but it appears that with List Accounts, the wallet:accounts:read permission is still required. I get a 401 error without wallet:accounts:read even though the user has granted access via the interface denoted above with the selected wallet.
I would rather not use more permissions than necessary. In this case, I am only wanting the selected wallet as denoted by the interface above, not every other account which is what wallet:accounts:read provides. Is there a permission I am overlooking here, perhaps?
Thank you for any continued assistance/clarification you can provide.
Unfortunately, this is not mentioned in the documentation. To prevent future confusion, we will soon be updating the documentation to include more up to date information about this endpoint. Thanks for the feedback!
As for the List Accounts endpoint, a wallet:accounts:read permission is required to access the user’s accounts and their balances. You may opt to have additional scopes for additional information or access.
To further assist you with the issue you are encountering,
Can you provide us a screenshot of the issue you are encountering?
What are the steps you have taken?
What permissions did you remove/add from the authorization of your application?
Once you send us the information requested above, we’ll work to quickly address this issue.
Thank you very much for the assistance @Anonymouse.
As for the List Accounts endpoint, a wallet:accounts:read permission is required to access the user’s accounts and their balances
So there is some confusion here. In the screenshot above, the user is selecting a wallet, but the wallet:accounts:read scope is not provided in the authorization URL.
If the wallet:accounts:read scope is required to access the wallet that is being selected by the user, and the scope is not actually being requested (either by URL or by application settings), why is the user being asked to provide wallet access? It would seem that it would either:
Not show a list of wallets
Show a message/error
Please let me know if that makes further sense and/or if I should provide more information for you.
With regards to your concern, as of the moment there is no other API endpoint aside from the List Accounts or even permissions that would only retrieve the authorized wallet/account set by the user. Also, we want to clarify that the wallet that the user should select to authorize is not related to scope/permissions at all, but with the Auth URL. Developers can add parameters to the Auth_URL to include which account/wallet should be authorised with the account parameter . If nothing is specified, the Auth_url will always default to “select”, which allows the user to select which account/wallet they want to grant permissions, even if there’s no scope wallet:accounts:read added. If you are to utilize the List Accounts endpoint, you should add that to the list of scopes.
Thank you for your continued assistance and insight @Anonymouse. I am aware of that setting to allow all or select. I would prefer to set this to the default, select.
I am still unclear, however, after the user selects the wallet, how I as the application am supposed to know which wallet they selected. If I understand correctly, the only way of finding this out is to assert wallet:accounts:read and read the first element from List Accounts.
That stated, it is confusing to me to have the user select a wallet to associate with my application without applying wallet:accounts:read, when it seems that I need this scope in order to see the wallet that they selected. If my application can only see the wallet they select with wallet:accounts:read asserted, then why are they being provided an interface to do so when wallet:accounts:read is not being asserted? This seems like a bug and the interface should only be shown if I am asserting the wallet:accounts:read scope.
Thank you for any further clarification you can provide. Please do let me know if I have something misunderstood, of course.
Hi @Mike-E! We apologize for the delayed response. We appreciate your feedback and we would like to recommend that you post this in the Feedback Section of the forum. Every feedback like yours is very valuable to us. Thank you and have a great day!
Hi @bazinga / @LaRisa / @Lioness there appears to be a recent issue that has developed with this API call, can you please confirm?
If order = “desc” is provided, I get an empty list of accounts from the user. This used to work as expected, and there was at least one account that was returned: the one the user selected.
Now, again, the result is an empty list and this now throws an error in my application. Additionally, it appears that the pagination.order field is also returning as a blank string which results in a thrown exception upon serialization.
Note that if I supply order = "asc" I do get a response, but the account returned is always BTC.
Any guidance/suggestions/insights would be greatly appreciated as this is impacting my application and the customers who use it.
Looks like @bruuuh and @LaRisa are the only users with activity in the past month. Everyone else I looked up has had zero activity since April, which is most concerning as this forum was an excellent resource for support and inspired a great deal of confidence in using its services.
There is also @Kevin.Dooley who may or may not be still employed at Coinbase. Thank you for any update you can provide for this issue currently impacting my customers attempting to use your technology.
Thank you @bruuuh, @LaRisa, @Kevin.Dooley for any assistance you can provide on this issue impacting users using your technology in a production environment.
There appears to have been an unannounced breaking change here:
As a result of this, I now get an empty account list when supplying a sort order of desc, and the wrong account (BTC) when supplying asc. This seems incredibly broken.
Thank you for any assistance you can provide in addressing this issue.
Coinbase Devops was gracious enough to revert the unannounced breaking changes, but apparently, the issue that I am facing is different from this as it still persists.
When performing a limit=1 on an API call, the result set returns limit: 0 in the resulting JSON, or an empty set.
I share this as there have been a lot of corporations coughTwittercough that have done everything in their power to take support away from customers – even ones that pay! It is great to see someone out there still taking time to interface with customers reporting issues and finding ways to see what is going on. I am very appreciative of this.
I was bummed to see staff reduced here on the forums, but I am happy to see you still have viable support where it matters. Thank you.
I will never doubt Coinbase again. Your support is some of the best. Well at least for those of us who are on the Exchange Ops. I suppose going forward I will use that channel, but I still think it’s valuable for those who are exploring Coinbase/API to know what they are in for, both positive and negative.
All this is to say that my problem is now addressed. Some issues required back and forth, but the team managed to solve all of them and now my application works as expected.
Thank you very much for all your efforts out there. They mean a lot!
Thank you for any update you can provide for this issue currently impacting my customers attempting to use your technology.
