EOL Data services


Thanks Jen. The hierarchy_entries API is my highest priority too, I appreciate your efforts on this and all the other fronts.




@hammockj curious if you have a timeline for hierarchy_entries returning? deciding whether to pull that functionality out of taxize temporarily or just wait on this


looks like today or tomorrow for hierarchy_entries


{ <identifier>: <result>, … }
but I am now getting an array
[ <result>, … ]
Is this change intentional?

No. I’ve just fixed this, sorry! …Should be pushing the new code today.


Yes, that one is “correct” in the sense of how the controller renders objects, and “fixing” it to mimic the old API would be more work than is (IMO) warranted. Sorry about that. If it’s a show-stopper, we can, of course, put in said work!


@mmvitale @Natasha @gregm @navidz @sckott please note for Pages, (batch and non batch) @jrice’s responses just above. Batch results should have reverted to an object mapping now, non-batch format will stay the way it is. Docs will be updated. Thanks for your patience!


@gregm @sckott @divinglog @OLDY hierarchy_entries should be working now, if you care to try it. Please let us know if you see anything unexpected in the form.

Please note that for this service in particular a lot of data are still missing, if you’re interested in specific classification providers. We’re hoping to have NCBI and CoL in within the next week or two. WoRMS and paleoDB are present now.


Hi Jen,

The hierarchy_entries API seems to be working as expected for me. Thank you for getting this done.

I have checked a number of marine critters and many of the services available for each critter. I’ll keep testing, but so far so good.




There is a subtle distinction between two recent changes to the results from the pages API. There is the change that has the higher level taxonConcept attribute that you’ve explicitly addressed (and which will not change). The second change that @sckott and @Natasha and I mentioned was the extra level of array that was added to the taxonConcept attribute. When v3 was first released the structure was: {“taxonConcept” : {}} and as of a a day or so ago it switched to {“taxonConcept” : [, {}]}. Can you confirm that this extra level of array is what we should expect going forward?

Either way is fine, I just want to make sure.



Sorry! That was a regression (bug). …Fixing that right now…

UPDATE: I’ve fixed it, but cannot push the new code right now due to some technical problems. I’ll reply here when it’s available.


Hey guys,

So when I use API to call for the name of species with taxon id 50962909, I will get the results and when I use the browser I also get the same results, but when I use Cypher, I get nothing. My Cypher code is something else but even the simplest Cypher code as bellow will give me no data:

MATCH (p:Page { page_id: 50962909})
RETURN p.page_id, p.canonical

Does anyone knows why?



That particular page has no data, and thus isn’t included in the TraitBank (neo4j) database. :\


correction, @jrice @navidz: that page is not in our default classification, the Dynamic Hierarchy, and so isn’t found in the graph. You’ll see “Unresolved name” in the title of such pages in the interface. Taxa with no data are included in the graph, so you can do taxonomic queries this way, but you’ll only see taxa in the Dynamic Hierarchy. This represents a basic level of taxonomic curation.


I want to see how the new Cypher API works.
By the looks of GitHub doc, it can only be called from server-side scripts?
Can it be called via client-side JavaScript?
Where do I start?


I can’t get the images_page parameter to do what I want.
If I call:

for both requests the data object returned is the same, am I doing it wrong, or is something broken?


Thanks for reporting, @justinpinkney. I think you’ll find an additional problem with that query, if you want Zebrasoma flavescens. That form was incidentally supported in v2, but now it will bring you content for taxon page 1 (Metazoa). Try https://eol.org/api/pages/1.0/46577088.json?id=&images_per_page=1&images_page=1

That being said, the pagination doesn’t seem to be working. Stand by…


This is a good question, thanks for asking it. Ordinarily you would access web pages from Javascript using XHR, yes? If this fails, I think it will be because your browser is over-protecting EOL via SOP and what we need is a CORS exception to override SOP. (Enough acronyms yet?) I will check to see if the service is returning sensible CORS headers, or you can. Will get back to you.


@OLDY, I’ve checked and the service does not at present provide a CORS header for the response, so any XHR response will be blocked by the browser.

I will look into having this added. But, in the meantime, we have another problem if you are talking about accessing the cypher service from a public web page: unless you take unusual steps to protect the token, the token will effectively become public. I’d like a little more information about the application before encouraging this.

(I don’t think we’re committed to using secret tokens in the long run; they are there now just from an abundance of caution.)


Apologies for the LOOOOONG delay (we had a technical problem that needed fixing), but the pages API should have been updated today, and the odd array response should no longer be returned.


@jrice Thanks for getting that fix out. Just noticed a new issue though. It seems as though the images_page parameter is causing a 500 error?