Tag Archives: APIs

Here you can find blog posts related to APIs and their role here at Open Library.

Importing your Goodreads & Accessing them with Open Library’s APIs

by Mek

Today Joe Alcorn, founder of readng, published an article (https://joealcorn.co.uk/blog/2020/goodreads-retiring-API) sharing news with readers that Amazon’s Goodreads service is in the process of retiring their developer APIs, with an effective start date of last Tuesday, December 8th, 2020.

Deprecation notice on Goodreads API documentation
A screenshot taken from Joe Alcorn’s post

The topic stirred discussion among developers and book lovers alike, making the front-page of the popular Hacker News website.

Hacker News at 2020-12-13 1:30pm Pacific.
Continue reading

Announcing a new Read API

One of the goals of Open Library is to make it easy to share bibliographic data. While we’ve had various APIs available from the very beginning and have made bulk data dumps available since forever, there is always room for improvement.

We’re working on 2 new APIs at the moment, and today, we released a tiny baby version of our new Read API. The upcoming Import API was also released for internal use only, deployed as a replacement part for the process Open Library uses to discover new books (and their accompanying MARC records) that are scanned each day by the Internet Archive. (More on the Import API later.)

The Read API
Similar to the way our existing Books API mirrors and is compatible with the Google Books Dynamic Links API, the Read API is very much inspired by, and partially compatible with, the Hathi Trust Bibliographic API.

The idea is, you can hit the Read API with an identifier or a series of identifiers or an array of identifiers, and it will tell whether there is a readable or borrowable version available through Open Library. As you render a page in your own bookish website, you can paint links into Open Library based on the response.

Traversing Works and Editions
The Read API will try to match your identifiers to an OL edition record, and will then return its work and then other editions of that work which also have readable or borrowable resources if the one you’re looking for doesn’t have an available eBook. That way, you can at least point people to a similar version of what they were looking for if the initial query doesn’t find something to read.

I find myself wondering whether this functionality might be useful for other things, like reconciling works data across different systems, or comparing edition fidelity/duplication.

We were thrilled to bits to meet Dan Scott a little while ago when he came to visit us at 300 Funston. He’s a hacker on the Evergreen ILS system, and by day works at Laurentian University. Evergreen’s already been using the OL API for showing covers and tables of contents within their UI, but it was somewhat laborious, needing to blend two of our APIs together to get the desired output. It was great to meet Dan, and we actually ended up designing the Read API response together over the course of an afternoon, specifically to remove that double-step process. Dan has written about this too: The Wonderful New Open Library Read API and Evergreen Integration. The super thing about working with Dan is, once we’ve dotted the Is and crossed the Ts on this, it can be deployed to any and all instances of Evergreen that want it. (Hello, Koha? I’ll be in touch shortly!)

So, there are some initial Read API docs in the Developer’s area, and see a working demonstration of it that Dan & Mike hooked up in a flurry of late night emails and tweaking (which was a pleasure to observe). Head over to the Open Library skin on the Laurentian University’s library catalog to see very young API in action!

The obvious caveat is — as Dan notes — “working code wins,” which is another way of saying we haven’t optimized or scaled anything up for a bazillion hits yet, so results will be a little slow for now. But still! Books! In your catalogs! If you are from a large system that would probably send us a bunch of requests per second, it would be nice if you could give us a head’s up if you’re going to use the Read API. A good place to do that, or ask questions is on our ol-tech mailing list.

By the way, as you may have noticed, a few weeks ago, we mentioned that oclcBot has updated the Open Library with about 4 million OCLC IDs too, which means that if you speak OCLC, you can hit the Read API with your OCLC ID to look for things to read or borrow through Open Library on your site.

KohaCon10 & our API

I’ve just returned from a trip to Wellington where I presented about Open Library to the people assembled at KohaCon10. I had a lovely time meeting everyone involved, and was thoroughly impressed by the community that surrounds this 10 year old, successful open source project. A hearty congratulations to everyone involved! At the end of the conference, we were shown a fabulous Gource source code visualization of “10 years in 10 minutes,” which visualizes 10 years of Koha development. Seriously cool.

Continue reading

API with RDF/XML output available

It is now possible to access Open Library book metadata in an  RDF/XML format. The access is through the RESTful API. For an example, view:


The returned RDF/XML relies heavily on Dublin Core metadata terms, and uses some elements from bibliontology and the registered RDA schemas. Although soundly based on RDF, the output can be used like any XML and presents (most of) the Open Library metadata in the easily understood Dublin Core terms.

It has been suggested that this format include links to cover images, where available. It is also on our list to add tables of contents to the output. Other suggestions are very welcome — add them here, or send them to the ol-tech discussion list.

We’d love to hear about the uses you make of this API, and anything we can do to help you get more out of the Open Library.