Dashboard and API Limited to 1000 users

Help
1

I just imported about 14,000 users into our production tenant and only 1000 show up at a time both on the dashboard and in the management API. Is there a way to see all of them? Thanks.

2

The API will only return a maximum of 1000 users for a query. Other users are still accessible by changing the search query or sorting order. If you need to receive more than 1000 users at once, you should use the export endpoint or extension.

1 Like
3

Thanks a lot Thijmen for sharing that knowledge!

4

Thanks for the help. Is the a good way to get a total count of users who match a query without that 1000 user limit?

5

For as far as I’m aware, there’s no way to do that with the API… But I might be totally wrong here. We might need an Auth0 engineer to answer that one… @konrad.sopala? :innocent:

6

I see the Auth0 dashboard uses /stats/total-users to show a user count but I’m not sure if that’s available to use (it isn’t listed in the API docs). If it is available I don’t suppose I can pass a query to it?

9

to be honest, i totally dont get all this 1000 limit weirdness. It will result wrong totals in the Auth0 UI and will really hinder you to do mass updates on user through the REST API.
Dont get this limitation at all when there is paging on the rest endpoint. Thats exactly the reason why paging was invented in the first place :wink:

5 Likes
10

Exactly this. This is an aweful limitation for us.

1 Like
11

Can only agree, super strange limitation! During a migration we want to delete all users between the migration runs, and there is no function for that. The SDK only allows to delete one user at a time. With this 1000 limitation even with pagination we have to restart the delete script 40+ times to delete our 40k+ users. Imagine if you had 100k’s of users …

12

Just throwing in my 5 cents…

I suspect this limitation is to protect the Auth0 database and servers. Offset pagination is really bad for any database software once you go past a certain page because the DB has to read the old pages to get to the one you need.

I am reminded of this article OFFSET is bad for skipping previous rows

For batch jobs where we need to get ALL the users (initial migration, bulk updates, etc.) we switched to using the export job endpoint and wait (periodically ping the job status) until it completes, fetch the Location URI, gzip decompress and parse the JSON. For 20k users it takes a a few seconds (< 10s) Not ideal but works.

For the admin UI we will probably need to use the regular paginated method with the limit. However there might be something from the link above we could use.

Keyset “pagination” We need tool support for keyset pagination

On first load we fetch page 0 with 100 records (or however many you need) and force a sort by one of the columns (e.g. email). We note the last record email field (e.g. “fran@domain.com”) and make sure to send that information when the user requests the page 1.

Then when the page 1 is requested we send the request for Page 0 (yes 0, not 1), 100 records, sort by Email and filter by email > fran@domain.com. Fetch the 100 records, save the last email (e.g. xyz@domain.com) and return the paged data.

Drawbacks of this method are:

  • You can’t skip pages (e.g. from 1 to 5).
  • You need to change the GUI - you could have previous / next buttons only. Additionally send null email for the previous page and xyz@domain.com for the next page.