Proposed scope change to v3/application/users/me

[kev4ev]

Brief

I propose that the scope for this endpoint be changed from shops_r to email_r.

Detail / Use Case

When attempting to use this endpoint under the authorization of a user that does not have a shop (i.e. a customer) the endpoint returns a 404 response with the error: Could not find a shop for User with user_id = <userId>. 😿

To me it seems the purpose of this endpoint is to introspect the identity of the authorized user, but instead it's polluting the user resource with the shops concept. Further, the v3/application/users/{user_id}/shops endpoint already exists to return the shops owned by a given user.

Proposal

I propose the scope for the getMe resource be changed to email_r and return as it's body only { "user_id": "string" }.

Alternative

If there is another way I've missed to introspect the identity of the authorized user (user_id and/or primary_email) using their access token please let me know as this is integral to my use case / app functionality.

Thank you! 🖖

[PMStanley]

I'm not following your use case. If you're using OAuth (which you have to be to use scoped endpoints) you already have the userID, it's part of the access token. At which point you can already get the users shopID from the getShopByOwnerUserId endpoint which only requires API key auth.

I always assumed getMe was introduced so developers had an convenient way to get userID/ShopID in a single call rather than extracting the ID from the token and getting a sizeable response object from getShopByOwnerUserId when they may not need or require any of the additional info and were simply looking to get the shopID alone.
Moving it over to email_r auth would grant the developer access to personal information about the user that they may not need and this may also impact a customers willingness to grant access to the app.

The APIs primarily provide shop related or seller related information, what endpoints do you see your non-shop owning customers using?

[kev4ev]

Therrre it is. I missed the part in the docs about the user_id being returned as the first part of the access_token. Thank you!