Allow Project search API endpoint to count total results higher than 10,000

Bug Reports
1

The Project Search API endpoint appears to cap the total_results field at 10,000. Would it be possible to let it return the actual number of projects that match the input parameters?

Example: using this call for Uruguay: https://api.inaturalist.org/v1/projects?place_id=7259&page=1&per_page=1, I get the total_results value as 381. However, for some countries, such as the US or Canada, this number is limited to 10,000 (see https://api.inaturalist.org/v1/projects?place_id=1&page=1&per_page=1).

This issue is similar to this https://forum.inaturalist.org/t/allow-taxon-search-api-endpoint-to-count-total-results-higher-than-10-000/9327

2

It’s not clear to me that this is a bug since there’s no evidence that the functionality isn’t intended. It seems like it should probably be a Feature Request, since you are looking for additional functionality. If there’s a reason that this should be a bug, please let us know, but otherwise I’d suggest making a Feature Request, and then we can close this thread.

3

if you all think it needs to be a Feature Request, couldn’t you just change the thread to a feature request? most of the API endpoints do report total_results beyond 10000. this is one of maybe 2 or 3 that do not. it seems to be an oversight rather than intentional, but only staff would know for sure, i guess.

4

For feature requests, we would want the template filled out which shouldn’t be too hard.

I have no personal knowledge of whether the behavior is intentional or not - I’m mostly just noting that how it is treated would depend on that.

Two followup questions:

I notice that the API call links above are to v1 - is the same issue present in v2? Most of the development would be toward that I would guess.

Also, if you think the behavior may be a bug affecting multiple endpoints, you could list the other ones and they could all be checked/assessed and perhaps changed together (assuming there is a need).

5

it’s the same in both. i’ve never looked at the internals of the API routing, but just based on how i’ve seen it behave, i would guess that v1 and v2 share the same underlying bones. addressing this issue in one will likely address the issue in both.

it’s a slightly different issue (since a page maximum seems to operate here, too), but the one that comes to mind is some variations of GET /observations/observers?order_by=species_count (in both v1 and v2). compare:

the only other ones i can think of off the top of my head are new endpoints that exist only in v2: GET /users and GET /places. i don’t think that lack of a proper count in total_results really matters for these based on the currently available parameters, but if they were to ever get more useful parameters, it might be useful to also get more useful total_results.

there may be other endpoints that have similar problems, but if they exist, they are ones that i don’t use much. so i’m not going to go through and try to identify each one. iNat developers probably could scan the code to find these easily if they wanted to do so. from my perspective, the important thing is that this sort of behavior is not shared by most endpoints, which suggests oversight rather than intent.

7

I made the Feature Request. Thanks @pisum and @cthawley