Does anyone know what would be preventing the blocked: true/false attribute from being included in the users’ profiles when hitting the ‘/api/v2/users’ endpoint? I am using the Non-Interactive API Explorer client which is authorized to use the Management API. There are several other attributes that are not included (e.g. “phone_number”, “phone_verified”, “family_name”, etc.) but I am not concerned about those.
What would prevent attributes from being included in the users’ profiles when trying to list or search users?
I could not reproduce this situation by performing the following steps:
- Ensure a database connection user with email
user@example.com exists;
- Going to the previously mentioned user profile in the Dashboard and selecting the Block User action from the menu.
- Performing a GET
/api/v2/users?q=email.raw%3A%22user%40example.com%22&search_engine=v2 request.
The above steps lead to a response containing the blocked: true attribute/value. I also then unblocked the same user and did another search request which showed the unblocked change. The user search is not synchronous in relation to the operation that updated the user so in a normal scenario there may be a slight delay, but in general it will be almost instantaneous.
You mention that you observe this for other attributes; can you also indicate what happens if you update the user metadata through the dashboard and then perform a search that would return that user (if you repeat the search after some time/seconds is the result the same). In addition, updating the question with the exact type of user (connection) and the exact steps on how it was created/blocked/updated
may be helpful for troubleshooting purposes.
Thanks for the reply. I should have provided more context. I am authorized to use the Management API because I was given the Explorer Client ID and Secret, but I do not have access to the Dashboard (not my auth0 account). Using my own auth0 account, I was able to get all attributes including blocked: true/false for “fake” users that I created.
My process for retrieving a list of users is:
- Generate an access_token using the Explorer Client ID and Secret
- Use the token to perform a GET
{auth0_domain}/api/v2/users
I get all attributes for my account, but not the other account
Well, in that situation thing are a bit messier because the process is correct, but without access to the other tenant we can’t really pinpoint the possible source of the issue. For example, if those users don’t have those attributes set then it would be okay and not really an issue the response not including them. This is particular important for phone related data as not all users have that information.
As @jmangelo pointed out in the comments, the field was only returned if it was set. Someone with access to the Dashboard intentionally blocked a few users so that I could test, and the field blocked: true was returned for those users when performing a GET request to /api/v2/users.