Mendeley Data API launched!

Just over a month ago at the Mendeley Open Day, we launched Mendeley Data, and the number one requested feature has been to allow people to create and retrieve datasets via an API.


In the spirit of this festive season, we’re offering the community a gift – now you can use a REST API to create, manage, publish and find datasets. This means anyone can integrate it with their Apps and tools. In fact the Mendeley Data website is entirely powered by the API, which means that you have access to the same API capabilities that we use to develop our web app.

If you’re interested in working with datasets via our API, you can read our documentation here. If you’re new to the Mendeley API, you can get started by visiting our developer website, where you will find information about the API including authentication, documentation and examples.

But wait, we’ve got one more festive present for you! An early adopter of the Mendeley Data API is Hivebench. Hivebench is a digital lab notebook (DLN), which helps to plan and run experiments. Thanks to the Mendeley Data API, any data or observations can easily be shared to Mendeley Data from the Mac, iPhone and iPad apps.

Hivebench logo

We’re excited to see what you will make with our API. If you have any questions, or have created something cool, let us know at or on Twitter.

How I prepared for moderating my first panel discussion.

I’m currently doing a ground speed of 866km/h with another 6 hours 51 minutes to my destination.

That destination is API Strategy and Practice Conference in Austin, Texas. I’m off to chair my first session – the microservices session. I’ve just penned my introduction after 3 glasses of wine after watching the Love & Mercy film about Brian Wilson (excellent film by the way).

I thought I’d write a post about how I feel pre-first-panel-discussion-session-organiser-event. I keep worrying about the level of detail I should go into in the 5-minute introduction. Do I lead with a statement of fact about microservices and APIs running the world?  “What would Mike Amundsen say?” – something more profound no doubt. I had a dream last night that it was all chaotic and nobody listened and it was the worst session of the event.

I plan on a basic introduction of who I am and what’s about to happen. Unlike Mike Amundsen I am not an industry expert but I do have some expertise in being involved in a very difficult (ongoing) migration from a monolithic application to microservices architecture. This is one of the reasons I got asked to do this session.

The format of this session is about 1-hour 20 minutes. There will be 3 speakers doing a presentation of 15-20 minutes each followed by a panel discussion with all the speakers plus some additional experts in the field to have a ‘chat’ about microservices.

Thing is that as the session organiser (with help obviously from the API Strategy Team) it feels anything but a ‘chat’. I feel immense pressure to deliver an excellent session especially given how popular microservices are. I really want the attendees to walk out of the session and be able to do one positive thing in the office the next day.

However, I’m starting to think maybe the entire audience have been doing it longer than us? Maybe they all think it’s a fad and will go nowhere? How do I pick the questions that I should ask? What if I fall off stage? What if… ?

If you are reading this and you are preparing to chair your first panel discussion then here is how I’ve prepared:

  • Read about how to run a panel discussion.
    • I like talking (understatement of the century) but I’m the one person who should be doing the least amount of talking. Understand what is expected of you from a discussion. You may feel the crowd is relaxed enough so you may be able to let go of some etiquette.
  • Do your research.
    • I bought a copy of Sam Newman’s book on Building Microservices. Why? Internal concepts do not translate to external conferences. Find the common languages so you can speak generally.
  • Research your panel and reach out
    • Reach out to the speakers and ask how they would like to be introduced. Usually, they have some bio that they like to share about their achievements. It’s also important to give them some notice of how you are planning to run the session. It’s difficult enough to be on stage with a microphone, camera and lights in your eyes so let them know what you are going to ask. Even better – get them to suggest the content that they are comfortable with.
  • Reach out to your team
    • I emailed all the devs on my team and asked them ‘what would they ask an expert panel about microservices? ’ This will give you a good basis of what you should be asking.
  • Be prepared for feedback.
    • In fact, I would say go and seek it. If you want to improve then you need to accept feedback.
  • Accept that you will not please everyone
    • Its hard at conferences right – you have the noobs and the experts and it’s really difficult to please everybody. Just accept it.
  • Enjoy it
    • I remember the first time I was given a microphone and I was like ‘What the heck do I do with that? How do I hold it?” Embrace the new experience. You’ll love it.

OK only 6 hours and 7 minutes to go until I land. I wonder how much of that advice will make sense in a few days time after the session. I’ll report back.







The first year of our API!

On the 18th September we will be celebrating the one year anniversary of our API. As part of this celebration, we’ve been looking back at some of our achievements over the past 12 – 18 months.

All of our existing internal clients have migrated onto the new API, and we’ve built new clients such as the new web library as well as the just recently released Android client. Additionally,we’ve embraced new clients such as Overleaf, Open Science Framework and Labfolder; all the while continuing to support the “old timers” such as PaperShip, ImpactStory and KinSync.

Unfortunately, we’ve had to some farewells in the process: Scholarly, which, for a long time, was the the unofficial Mendeley Android client,decided to not proceed and therefore did not migrate onto the new API. The developer, Matthew Wardrop originally built the app for his own personal use but now would rather use the Mendeley client. We wish him all the best and want to extend our thanks for his contribution.

Speaking of contributions, we would like to give a special mention to an ex-colleague Matt T who went on to greener pastures. We can’t thank him enough for his technical wizardry in beginning our API journey.

One a personal note, it has been a year of firsts for me. I gave my first meetup presentation, there was my first time using a microphone (still can’t believe someone let me have one), my first conferences (internal and external), and my first content panel discussion. Despite the stomach churning fear that I’ve felt for each one of these first timers; I am grateful to have had the opportunities.

The achievements of the last 12 months and beyond have been due to a massive team effort.  I would like to thank all my colleagues; the API developers, the client teams, the hack organisers and the wider development community for building great tools and Apps to help the lives of researchers. Special thanks to our community team for their constant support and a massive shout out to the wider API community at all the conferences and meetups for providing a safe and encouraging environment.

Finally, thank you to Elsevier for our kick ass new office!


Labfolder and Mendeley integration – from a new API to a new App

With the update of the Mendeley API last September, it was about time to give the Labfolder Mendeley Extension a polish as well.

Labfolder is an online tool where laboratory scientists can plan, document, and evaluate their experiments all in one place, allowing them to focus on the tasks they enjoy the most: making discoveries, developing new hypotheses and finding new applications. Just like Mendeley, Labfolder is available online, as well as on your Android or iOS devices.

Laboratory work and scientific literature go hand-in-hand, and so it was a no-brainer for us to integrate Mendeley as one of the first Labfolder extensions, allowing researchers to read, integrate and cite their scientific literature, whilst planning and conducting experiments. Additionally, laboratory notes and experiment details can also be uploaded to Mendeley directly, allowing researchers to manage and share experimental notes within the literature database. The API integration with Mendeley therefore closing the gap between laboratory and literature.

To see how the Mendeley integration works, watch this video:

When updating the integration of Mendeley in Labfolder, the new Mendeley API provided us with new functionality that permitted significant improvements:

Firstly, the API update allowed faster loading of the library. In the previous versions of the API, an identifier had to be retrieved for every document in the library. With this identifier, the metadata (author, title, year of publication etc.) would be retrieved for every single document. With the new API, it is possible to retrieve the entire library with one API call, allowing a faster access to all documents, even when the Mendeley library is quite large.

Additionally, the new API allows the display of file names of imported literature. When importing PDF files, including scientific literature from Mendeley into Labfolder, the previous version of the API did not support a handover of the name of the original file. With the new API, the file name of the original file is automatically imported as well, making the management of literature content within Labfolder a lot easier.

We are happy that, together with Mendeley, we can bring these improvements to help researchers with their work. Future improvements will, however, not only depend on technical innovations, but also from the input of you, the users! In order to help us to further improve, please do the Labfolder team at and tell us how you like the new Mendeley App – and what we can do to make it even better and your life’s even easier.

Thanks to Sarah Hoey and Florian Hauer for writing this blog post.

Elsevier API Guild

Last week Ian Evans, Elsevier Communications Business Partner wrote an article for Inside Elsevier; an internal news channel for employees, announcing the Elsevier API Guild. I wanted to give some background on how it came about, what is a guild and what the goals of it are.

Back in April I attended the first Elsevier API Summit in New York City. This event brought together teams from all across the business such as Mendeley, Research Solutions, Science Direct, Scopus, Operations, Technology and much more.  “We wanted to get together the people on the ground, who build and run these things, help them meet people they hadn’t met before, and show them that they weren’t alone in addressing these issues.” said Ale de Vries, Product Director, Platform Integration, Research Applications & Platform. Ale and his team were instrumental in getting the conference organised.

The Summit also looked at how Elsevier’s customers are putting APIs to use. Already nearly 50% of Scopus customers are currently using its APIs, using it to show citation counts on their websites, or to add Scopus metadata to their own research information systems. For Elsevier, it makes for a meaningful way of adding value to the platform, as well as providing more visibility for the company: many customers use the Journal API to display Elsevier’s Source Normalized Impact per Paper (SNIP) and also the SCImago Journal Rank (SJR) metrics. These are calculated for the 20,000+ journal titles in the Scopus database.

We seen presentations on how company’s are using APIs for text mining, or to analyze and evaluate the different approaches to collaboration, or to link Reaxys to lab equipment and provide meaningful analysis of substances in near-real time.

As the Summit was wrapping up everybody remarked on how useful they found it to share experiences with other colleagues in other departments. Attendees were suggesting that we come up with an API guild. “The concept of a guild has come up a few times, where people self-organize around a common theme,” said Ale. “We’re looking at how to leverage that structure around the Summit attendees, and give the conference a home within that guild.”

Ale defined the guild as:

The API Guild is the professional organization within Elsevier for people building, deploying, managing, and supporting APIs.

There are many facets to owning an API and so Ale would require a small team to help lead this guild which includes myself and a colleague of ours Jim Slaton (Enterprise Architect).

The goals of the guild fall under three broad themes:

  • Business – help Elsevier maximize the business value of APIs
  • Technology – inform technology choices and design to provide this value at optimal cost
  • DX – establish developer experience (DX) as a key aspect of the company’s customer focus

3-Circle Venn Diagram (Plain) - Plain

We are still establishing the guild and getting some of the admin side of things out of the way but once we have this complete we can concentrate on our main responsibilities which are:

  • Be responsible for periodically organizing the API Summit;
  • Ensure that the API Summit will produce concrete actions in support of the Guild’s goals;
  • Between Summits, co-ordinate collaboration amongst Guild members and other stakeholders in order to execute these actions.

Elsevier can’t resource, build and distribute all the great ideas. We should embrace the innovation of others so we can accelerate research and improve research workflows at every step. By opening up our APIs we can build on existing partnerships, build new ones and create a rich ecosystem so all researchers and science can benefit.

Special thanks to Ian Evans for allowing me to share some of his original article. Generated the Venn diagram using Lucidchart.