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.
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!