With an API even more than other features you have to aim for conceptual integrity to ensure the API contracts survive as long as possible.
Interview with Dan Gravell, founder of Elsten software.
Dan is a software developer made entrepreneur. He is the founder and only person behind Elsten software which produces software and services to enhance people’s experience when it comes to digital music.
Tell us more about Elsten Software
Elsten software employs just one person (me) and is based in London, from my office at home. I started elsten software in 2009 and about a year later got revenues to the point where I could leave my day job and concentrate on the company full time.
The aim of elsten software is to make digital music collections manageable. I don’t just mean allowing them to be editable, I mean enforcing constraints so they are easy to navigate, browse, choose music to play and so on. To do this I think you need consistency, completeness and correctness of musical metadata (what I call the 3Cs).
To that end the original product was simply “bliss” (http://www.blisshq.com) which was downloadable software. I was then approached by a few people to use bliss’s cover art lookup functionality. So I decided to move it online as an API which bliss and other clients could use, as a new product.
What API(s) does Elsten Software offer today?
A music metadata and cover art lookup API. It’s ‘release based’, meaning only information about releases (albums, singles, compilations) and actual discs (CDs) can be looked up.
To search for information you can use release and artist names, FreeDB disc IDs, MusicBrainz disc IDs and Acoustid audio fingerprints.
Data is returned in JSON format.
When did you realize that you needed an API?
I’ve wondered about doing this for a while because when other online APIs changed I would have to update bliss and release a new version. It seemed like a good idea to have this feature in the cloud and then I could always update without releasing and distributing new versions, reducing support costs.
The motivator was when someone approached me asking to use bliss’s cover art lookup logic. I realised this might be a good product, so that was the key driver.
What recommendations and tips would you give to a company planning to launch an API?
While you need to accept feedback from your users, with an API even more than other features you have to aim for conceptual integrity to ensure the API contracts survive as long as possible.
Why and how are you using 3scale API Management Platform today?
I use 3scale to manage user keys and report on usage. It has been invaluable in this, and was a relatively easy integration. Much easier than writing this stuff myself!
What benefits have you seen/are you expecting from your API program?
From a business point of view: new revenue sources and opening up of new markets.
From a product point of view: lower support costs for my downloadable software.
What is your vision for your API?
I would slowly like to move more features of bliss into OneMusicAPI. That would include ways of customising the returned data. For instance, the “genre” for a musical release could be any conceivable character string.
It could be a very specific genre or a very general one. Using bliss, any input genre can be transferred to the user’s “consolidated genre list”.
In OneMusicAPI, you could create the same genre list and all data you lookup could be thus transformed. Other examples would be control over title case, cover art sizes, track number padding and more.