Yeah, I didn’t go about using /v1/taxa/autocomplete to get that info. It’s just what I ended up using to accurately match what the user types to search for a taxon. Using /v1/taxa?q=<query> was too prone to result in the topmost item from the search not matching their expectations, whereas /v1/taxa/autocomplete gave better results for that. Since autocomplete doesn’t give all the info needed now that I have added establishment means and conservation status to the bot displays, Dronefly will now also do a hit against /v1/taxa/:id to get whatever was missing from the first call.
As a side issue, the conservation_status JSON responses are a bit of a mess, too, because /v1/taxa/autocomplete returns the status_name but not the url, and I want both. Conversely, /v1/taxa/:id returns the url but not the status_name. So when the bot does retrieve both, I hacked my way around it by synthesizing the result from both calls. Unfortunately, there are circumstances where the bot retrieves a taxon record without a text query, and in that case it’s only using the id#. In such cases, my displays degrade from saying that polar bears are “threatened (T)” in the US to saying that they are “T” in the US, because it’s missing status_name. But perhaps discussion of this issue really should be split off into a whole other post.
I’m encouraged to hear you have ideas about fixing the original issue though. Looking forward to seeing the results of your efforts.