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?
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.
I’m also seeing errors when trying to load “text” data_objects. Here is an example:
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.
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!
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.
The taxize library in R
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.
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.
I’m no admin but the API usage has changed.
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
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.
As a workaround you could use a proxy like https://cors-anywhere.herokuapp.com/ e.g.
@daniel_hartley Thank you. I am aware of workarounds.
But it is not very clean, is it?
I will wait for admins to figure out what has changed.
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.
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?
Yes, the previously included query does show the issue.