-
Notifications
You must be signed in to change notification settings - Fork 309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistencies with API documentation #564
Comments
Hi @tommedema 👋 Thanks for raising this, and sorry for your frustration on this. I don't disagree there should ideally be parity there, but I'll let someone with more familiarity with this particular SDK's API address your concern there. With the holidays it might be a few days before that happens. I'm not sure if you were having a specific issue around the example you raised, but I just thought I'd point out that you might consider using the getUsers endpoint to achieve what you were suggesting there. For example:
Again, not sure if you raised that just as an example or if you had a real world issue with that particular endpoint, but I thought I'd offer that advice at any rate. Thankfully you wouldn't need to do direct HTTP requests for such a situation. |
@evansims thanks but that endpoint is not immediately consistent unlike getUsersById and getUsersByEmail, see also https://auth0.com/docs/best-practices/user-search-best-practices because it is possible to create multiple users with the same email across different connections, we need to be able to verify that an email does not yet exist prior to creating a new user per our requirements -- and this requires immediate consistency |
Thanks @tommedema for raising this. In order to avoid a breaking change, we could introduce the ability to pass in an options object OR string. It could look something like this: getUsersByEmail('[email protected]', cb)
// or
getUsersByEmail({ email: '[email protected]', fields: { stuff: 'here' }}, cb) |
@davidpatrick that seems fair; also, do you know who would update the relevant typescript bindings? |
@tommedema I will take a look |
@tommedema to update about the typescript bindings, we are assessing bringing those bindings into this repo. You can follow that decision here #572 |
For example, getUsersByEmail clearly has support for field filtering by passing in the "fields" argument:
https://auth0.com/docs/api/management/v2#!/Users_By_Email/get_users_by_email
But the sdk completely ignores these fields and only accepts an email for getUsersByEmail:
node-auth0/src/management/index.js
Line 1018 in 06304e0
Can we bring the sdk back to feature parity? There's little point in using an SDK if we have to go back to doing direct HTTP requests to actually access the complete API.
The text was updated successfully, but these errors were encountered: