On the future of our Open API: feature updates and eating our own dog food

There have been a few guiding principles that have directed the progress and business strategy of Mendeley from the very beginning, and chief among these is our mission to make research more collaborative and open. We want to build a bridge to a more modern way of using the web for scholarly communication.

To that end, we’ve been hard at work lately improving our Open API, as it’s a critical part of our strategy. We currently serve more than 100 million API calls per month to about 260 third-party apps. In addition, our API powers the analytics dashboard of the Mendeley Institutional Edition, and powers the Institutional Repository sync via Symplectics Elements. We hope to see the numbers of client applications grow, and to that end, we’ve made some fundamental changes to the API. Our overall goal is to further open up our data and extend third-party developers’ capabilities, so here’s a summary of recent and upcoming changes:

Merging external and internal APIs

For too long, we’ve run one set of services to power our own apps – desktop sync, web, and mobile – and a separate service for external developers. In addition to this, we’ve had some ad-hoc arrangements with developers to do things like import data from CiteULike. In February, we plan to end these ad-hoc arrangements, and have already begun to transition our internal services to the same Open API that external developers have access to. Our new iOS app, which has been rewritten from scratch and is currently in beta testing, is already using the Open API exclusively. This allows developers to leverage the scale of our platform, respond to the desire for an open source solution, and build clients that are as full-featured as our own. Using the same API internally & externally, aka eating our own dogfood, will spur us on to improve and extend it rapidly. This ensures robustness & reduces maintenance burden, which frees up more time for further improvements. Over the next few weeks, we will work with developers to help them transition if they’re affected by these changes, so please get in touch if you have any questions.

New API methods

New user methods have been added to facilitate client development. There is now an update document method, which includes versioning, to make client sync more efficient. We are also transitioning to OAuth 2.0, which has recently been finalized and is easier to use than OAuth 1. Additional functionality is on the way. We’re very interested in improving services which are popular with API users, so please join our developer mailing list and tell us about which services you like, and which you’d like to see in the future.

Improved content quality

We have made continued improvements to the breadth and depth of our research catalog, as well as to metadata quality. Previously, some requests for document details would return only a uuid if the document was flagged as of uncertain quality. We’re now returning document details for all these documents, or a 404 if the document is not available. We’re continuing to work on improved error messages to give you more information about why a certain response was received.

Better Documentation

We have added more documentation to the developer section of the site and are in the process of migrating all of the documentation to a better system.

In summary, we’re going to invest considerable resources into our Open API to ensure it remains the best place for building research applications that reach a global community of academics. If you want to join us on that journey, see our careers page – we’re hiring Data Scientists!

8 thoughts on “On the future of our Open API: feature updates and eating our own dog food

  1. +1 for eating your own dog food. The other things I’d like to see is the ability to discover the social groups (i.e., who is reading a paper, subject to privacy settings), and the ability to discover the set of papers that have been merged into a single entry in the research catalogue (because this is occasionally goes disastrously wrong). Another change worth considering is making the JSON for a publication as close to BibJSON as possible, which seems to be gaining traction as a (loosely defined) standard.

  2. “260 third-party apps”

    Do you maintain a web page where these apps are listed / featured / categorized?

  3. I hope this is a step toward incorporating annotations support into the API—not being able to annotate PDFs in a Mendeley-supported way on a mobile device is the biggest downside to Mendeley for me at the moment! Mendeley is otherwise great—I’d love to be able to do all of my academic reading/annotating in one place with synchronization across devices.

  4. Love the rationale behind improving your Open API. Not only does a free flow of knowledge make it easy to share ideas and advance science, it is a step toward double checking for fraudulent results that give researchers a bad name.

  5. I first started using Mendeley a few months ago and had a bit of a tricky start. I had mendeley desktop installed on a work computer and on my home laptop. I reguarly worked on both and had a problem when trying to save PDF’s (from both at home and also from work).

    After a bit of investigation I found out that the problem was due to dropbox and which I believe now is not fully supported with Mendeley. However, after reading a number of forums I managed to get everything working in harmony and my setup now has been worth the effort.

    Mendeley is a great product and the development of the API can only improve a product that is one of my most useful citation resources.

  6. I love the dog food API analogy! We should all eat our own dog food its very nutritious and shows you have faith in it, if you are eating/using it internally and not just feeding it to your dog/customers 😉

    On a more serious note: Really love your API, planning to enter the Binary Battle 😀

Comments are closed.