Access Accessed Wallet

Hello all,

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!

1 Like

Great, thank you very much for your assistance, @KairoShie and team. :pray:


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.

We hope this helps!


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.

Hello @Mike-E !

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.

1 Like

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:

  1. Not show a list of wallets
  2. Show a message/error

Please let me know if that makes further sense and/or if I should provide more information for you.

Thank you for your continued assistance.

Hi @Mike-E!

Thank you for the clarification.

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.

Hope this helps!

1 Like

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. :pray:

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!

1 Like