Taxon search by name does not prioritise exact match

The v1 API doesn’t appear to apply a ranking to queries by name in terms of goodness of match. In particular, this query:

currently returns 381 results, where the expected exact match to taxon doesn’t appear anywhere in the first page. Since these are sorted by obs count it looks like it is somewhere beyond position 50. Given there are so many, I don’t know what ranking to apply in order to get the record I want other than querying for every page of results and then looking through them for “matched_term”.

I see this rather old GitHub issue suggesting it was once desirable to inject exact matches at the head of the list, but I imagine this applies to the old API.

Note that the API documentation for this endpoint at!/Taxa/get_taxa states “Name must begin with this value” but this doesn’t seem to be correct, instead it looks like a fuzzy name match is applied to all terms which are then matched against all alternate names.

It would be useful to somehow get exact matches preferred - I note that the autocomplete API at doesn’t have this problem so I guess is some kind of workaround. Are the rate limits more generous on the new v1 APIs than on the old-style ones?

i typically would only use GET /v1/taxa to return detailed information about a taxon, or to search by id or relationships, not to search by name. to search by name, i would probably use or GET /v1/taxa/autocomplete.

i doubt there’s anything the staff would consider a bug here, and to the extent that anyone would want to change the behavior here, i think that may already covered in the broad feature request here:

just based on what i’ve observed anecdotally, the rate limits generally seem to be the same across endpoints on all iNat APIs, although autocomplete ones seem to have slightly higher limits, and map tile ones seem to have high limits, too.