Child Item

Entries Count Differs from Requested Limit

I'm using the /list_folder endpoint using the Dropbox-API-Path-Root header to display content from a team with shared dropbox. When I use the limit parameter with a value of 20 this returns 16 entries. However, if I then make an otherwise identical request with a limit parameter of 500 I would receive 40 entries.

These numbers are consistent. It always returns 16 rather than 20. It always returns 40 when requesting 500.

The documentation the limit parameter does state that it is an approximation and that sometimes more may be returned.

If I know that more than 20 entries exists (because a higher limit does produce more than 20) how do I determine why a limit of 20 would only return 16?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

The page size returned by /2/files/list_folder or /2/files/list_folder/continue is not guaranteed, and the 'limit' parameter is the "maximum number of results to return per request". As that is only intended as a maximum, the server will attempt to not return more than that per page, but it is not guaranteed to return exactly that amount per page. Additionally, as you noted, in some cases it may even return slightly more than that amount per page.

Regardless of the number of returned entries on any given page and also regardless of the specified 'limit' value, the app should always check the returned 'has_more' value to determine if it should call back to /2/files/list_folder/continue to get more results. Please refer to the documentation linked above for information on using that.

MarshallDavis

While factual, and as evidenced by my observations, this doesn't help me understand why I might expect 16. Are some removed from the results after the page is selected? Is there something I can do to help fit specific files into pages?

Greg-DB

The actual number of entries returned per page depends on a few implementation details of how Dropbox works, but I don't have more specific details to share on how that works.

Apps shouldn't rely on a specific number of entries being returned per page though; apps should process any/all entries returned on a given page, and then check 'has_more' to determine if it should call back to /2/files/list_folder/continue, processing all entries on all returned pages until 'has_more' is false.