EOL v3 will launch with support for the core EOL v2 APIs: Ping, Search, Pages, Collections, and Data Objects. Documentation for these APIs will be available on the new site post-launch at this link. These APIs are meant for legacy use only. New services for media and text content will be available shortly.
Structured data in EOL is available via a new Cypher API Feedback and questions are welcome here or through our Github issue tracker.
All classic APIs became under protection of CORS? They used to not right? I am getting Access-Control-Allow-Origin errors when I call your API through my JavaScript. How do I use your API from now on?
Hello! That sounds like a misleading error message; sorry. You shouldnât need anything to maintain access, but we have been seeing back compatibility problems and are correcting them as they are reported. Can you post a sample of a query that gave you the error?
Jen
Iâm seeing some issues with the âclassic APIâ since it was launched. Per your previous post, here is an API call that is resulting in a server error:
this results in a â500 Internal Server Errorâ. The particular identifier used in this request came from this API call:
however all calls to the âhierarchy_entriesâ API seems to result in this error.
Thanks your attention to these issues.
Cheers,
Greg
Iâm also seeing errors when trying to load âtextâ data_objects. Here is an example:
https://eol.org/api/data_objects/1.0/12749603.json?taxonomy=false&cache_ttl=&language=en
this also results in a â500 Internal Server Errorâ. The data_objects API seems to be working fine with image object. The other thing that Iâve noticed with the text objects is that the no longer include the âmimeTypeâ tag as they did in the previous version of the platform.
The identifier used in the example above came from this API callâs response:
Again, thank you for your attention to these issues.
Cheers,
Greg
Thanks, gregm!
I reproduced your error with (lots of) text objects. Thanks for reporting; thatâs a surprise, but itâs possible text wasnât separately tested when we stood up the classic APIs in v3. Stand byâŚ
hierarchy_entries: worse news here, Iâm afraid. Most of our classification providers havenât been migrated in to v3 yet- we want to make a few more revisions to our native classification before trying to map them onto it- but when theyâre in, we donât plan to revive the old api, if we can possibly persuade its users to adopt a new one; the old version was a bit of a mess. The first alternate product we expect to have available is a bulk download; a new api will follow, but weâll be building it from scratch, not for back compatibility. If you can tell us about your use case for this service, that would help us ensure it meets your needs. Sorry for the delay!
Jen
quick update: weâve just heard from three saddened users of the old hierarchy_entries api, so itâs back on the table. Hang in there; it might be next week before weâve got a back compatible service stood up. We will still encourage people to use the new services when theyâre ready, but apparently yâall have users also, who donât love prolonged interruptions in your service. Weâll get that in place as fast as we can.
Thank you, that is good news (restoring the hierarchy_entries API)! Iâm also using this API to let my users import animal data into my application. Iâm happy to switch to the new API once it is ready, but it is important for me and the users of my application, that they can continue to use your great API in the meantime without interruption.
At iNaturalist, every EOL photo we were using is now broken because you folks apparently changed the URLs. We were using https://eol.org/api/data_objects/1.0/fed8714f01d8b175d591681bcdcf943a.xml?images=1&sounds=1&text=1&details=1 to get new URLs for data objects like fed8714f01d8b175d591681bcdcf943a, but now they return a 500 error so we canât even fix whatâs broken. If thereâs a different endpoint we should be using or, better yet, some way to construct a working photo URL from the data object ID, please let us know.
Hello. My API call is
https://eol.org/api/pages/1.0.json?id=281&details=true&images_per_page=30&common_names=false
If I call it statically, say, paste it on my browser address bar, it returns the result, but if I call it via JavaScript, error message says
Access to XMLHttpRequest at â https://eol.org/api/pages/1.0.json?id=281&details=true&images_per_page=30&common_names=falseâ from origin âMY WEBSITEâ has been blocked by CORS policy: No âAccess-Control-Allow-Originâ header is present on the requested resource.
Thank you.
Iâm no admin but the API usage has changed.
https://eol.org/docs/what-is-eol/data-services/classic-apis
Data Objects API has only 4 parameters now.
I donât know how your app works so I donât know if it helps but you can try something like
https://eol.org/api/pages/1.0/491995.json?details=true&images_per_page=10
It returns 10 image objects for a particular taxon.
Iâm sorry, @kueda; we had to re harvest all our content into EOL v3 to sort out the cumulative taxonomic mismappings in v2; we lost the data object IDs. We preserved the taxon IDs wherever possible; for your taxa, very few of those should be missing. If you return as far as the Pages api you should find new data objects.
@daniel_hartley Thank you. I am aware of workarounds.
I would load API results in my static PHP page first, then call it via JavaScript.
But it is not very clean, is it?
v2 APIs were all free to use from JavaScript and my app pretty much depended on it.
I will wait for admins to figure out what has changed.
I am using this call in client-side JavaScript. Itâs not exactly clean but it avoids a server-side call. But my use case is probably different than yours; I only hit the EOL API in a CMS not in requests made from the public website. Good luck whatever you do!
Hi Jen,
I just wanted to give you a heads up that as of yesterday (about 20 hours ago) the pages API call that I included in my initial report has stopped returning image data object results (this is true for all the items that I have tried from various searches). It was returning images results until about 1:30 PM PST (9:30 PM GMT) yesterday.
Cheers,
Greg
So just to confirm, there is no way for us to get new URLs for those exact photos knowing only their v2 data object IDs, is that correct? To quantify our frustration here, thatâs 107,000 photos that iNat users manually chose to represent taxa on our site that we will have to delete, so I just want to make absolutely sure thereâs no way to avoid that.
@gregm can you provide a sample query? A couple of filters were repaired yesterday around that time which may account for removal of previously returned objects.
reads more closely This happened to your query above?
@kueda v2 is still on our servers; it may be possible to go spelunking. My understanding was that iNat culture now favors using your own images wherever possible and your reliance on us for taxon pages was minimal. Is EOL in the loop for the selected iNat images also?