API management service Mashery has come out of stealth mode tonight and is now offering documentation support, community management and access control for companies wishing to offer public or private APIs. This is an exciting launch.
An API, or Application Program Interface, is the interface that allows developers to leverage some one else’s data or functionality to create mashups. The discourse around data sharing and collaboration has largely moved beyond urging companies to offer APIs – now the task at hand is to make the offering of quality APIs easy. That’s what Mashery offers as a service.
Mashery was founded by former Feedster team members Oren Michaels, Kirsten Spoljaric, Clay Loveless and Scott Rafer. Rafer is also the CEO of MyBlogLog (our coverage). The company was incorporated in May and received under $1 million in backing in June. Investors include Josh Kopelman, Jeff Clavier, Rajeev Motwani, Ron Conway, Ariel Poler, Dave McClure, David Rose, and Scott Kurnit. Kopelman, of First Round Capital, is the lead investor and chairman.
The future is going to be built out of APIs – though still controversial in some quarters today, in time they will be as common as corporate web sites are now. Who’s going to build the series of tubes that makes such a future possible? Mashery is aiming to get into that game early.
There’s a broad spectrum of mashup infrastructure service providers already emerging. Companies like Widgetbox let consumers easily mashup data and applications into their existing websites (see also tomorrow’s SpringWidgets), Teqlo and Ning are the next step up in complexity and StrikeIron targets the enterprise market (specifically the part of it that uses the acronym SOA a lot). Mashery is aimed at companies that already recognize the importance of APIs and developer community but want to save money and time by paying some one else to set up the support infrastructure and do it right. It has a different feel to it than StrikeIron, visiting the two companies’ sites will make some differences quickly apparent.
Thankfully, Mashery emphasizes throughout their site that users own all of their own data and can easily export it at any time. That data is stored and processed with Amazon’s S3 storage and EC2 elastic compute cloud. Thus scaling up quickly and affordably will always be an option for Mashery. This is a striking example of the kind of company commoditized storage and processing in the cloud make possible.
A free account with Mashery includes a wiki to annotate API documentation, a developer’s blog and forum – all with moderation, administrative control and your company’s branding down to the CSS. It feels to me like Basecamp for APIs. A full list of free features can be found on the site.
A Pro account includes metrics to track use, developer registration, key issuance and access management. In the near term future, Pro accounts will include support for payment processing for commercial APIs.
The company says that Pro accounts for a typical API and community will cost between $10k and $20k per year. They emphasize that this cost is much lower than even a single employee managing the project and doing continuing technology development.
The first APIs that developers can connect with in Mashery are the open source business search solution Baynote and the website personalization service Loomia.
I’m not a developer myself so Mashery’s service quality and performance isn’t within my abilities to review, but I do know that this is a startup that is emblematic of the direction that the best of the web is going.
APIs changing under the feet of developers building on top of them is a significant problem and providing an easy way to annotate documentation should prove very useful to developers. Security and easy access control are two of the biggest concerns that companies considering an API consider. If Mashery can prove an effective service provider in alleviating these kinds of concerns for their customers and the development community then they are going to be a key force in the realization of a future built of mashups.
seems that they’re planning to push the evolution of api management to the next step – back in time to the old ‘link exchange’ model…i’m not so eager to see every site out there do everything that every other site does but with a different interface and variations in output…no offense to you, but with something of this nature i’d be much more interested in reading the expert technical opinions of somebody who has actually developed and managed complex api’s, perhaps explaining exactly how it differs from the approach to api management used by google, yahoo and others….
good idea….we were going to launch our own developer api and this could be pretty helpful.
Dave – I see what we’re doing as different than “link exchange” – our goal is to take a lot of the headaches out of provisioning and managing APIs, whether simple or complex. The APIs themselves don’t change. As we bring on more and more different vendors’ APIs, developers should hopefully appreciate having a consistent platform for both community management and api management and security. We in turn will listen to feedback from the community and continue to add features and enhance the experience for API vendors and developers alike, across all the programs we manage.
Gloria – we’re happy to help! Drop by http://www.mashery.com, click on “Register your API” in the upper right, and as soon as you’re ready to get going, we’ll be there to help.
Cheers -
Oren Michels, CEO
This could be a developer’s dream. Nice.
trying to understand…
does mashery host the api’s they support or just provide a source of information/documentation for the api’s?
Matthew, they provide wiki, blogs, etc. around the documentation and manage access through their site only.
Seriously, I don’t get it. If I’ve designed an API, why would I need this? If I use the API, why would I need this?
Are they going to proxy my app API? As an API provider, why would I want that? As an API user, why would I want that?
Most everything I see at Mashery are things I’d want to avoid…..the rest are things I can get at lots other places.
Pos – Many thanks; that’s certainly our goal.
Matthew – We don’t host them. As Marshall says, we provide community tools, which we do host. But the actual APIs are hosted by the provider, while access to them is managed, metered and reported by Mashery. Hope that explains it.
Oren Michels
CEO, Mashery
Suppose someone gets really good at using the tools provided by Dapper (http://www.dappit.com/) which can produce a web api out of any website. This person could turn around and sell his skill to other website owners. Some owners would actually pay a person like this because they just want something done quick and right, regardless of where the web api is hosted. Of course, this assumes the website owners already appreciate the power of web api’s and have an immediate need for exposing their info via web api’s.
Oren,
How does mashery differ from what Grand Central (the first incarnation) was trying to do?
I do see value in a “store & forward” approach when someone is writing to multiple API’s but rather do one call to mashery and get all the data back in real-time & in the right sequence . . . since many API’s are stateless, you dont have the headache of managing timeouts, exceptions, and re-posts . . .
@ I don’t get it….
If you’ve designed an API, you want people to use it. If you want a significant number of people to use it, you need to have a rich developer support site. If a lot of people use the API, you need to measure (and possibly limit) its use. Each API provider can either roll all that from scratch, distracting from their core effort, or user Mashery. Mashery’s done it right, and it’s all we do. We’re expecting to be pretty darn good at it.
If you use and API, you want it supported richly and in a reasonably standard way.
@ Will – I’m not in a position to comment on what happened with Grand Central; companies fail for a range of reasons, many of which are beyond their control. Plus, that company launched at a different time, and at a different point in the evolution of web services.
As for your suggestion of a “store and forward” approach, we agree that this would be a very useful service, and we’ve discussed where on our development roadmap it should appear. For now, we have launched with a group of services we believe will accelerate the rate at which new APIs are offered for use, and therefore accelerate the development of many new applications. As this market evolves, we will supplement the vendor-focused offering we launched today with new features that take advantage of the breadth of services we manage to address the biggest challenges developers face in creating new applications. The service you suggest is definitely in line with the kind of roadmap we have in mind.
@ Don’t get it – I agree with Rafer, but I’d go on to say I also had the expectation that it would be a straightforward challenge to create the entire group of community management services – blog, wiki, forum, annotated documentation and static pages – with a single sign-on and a consistent user experience – by bringing together existing tools and tweaking the formatting and authentication settings. That turned out to be a fairly significant challenge, and maintaining it as each component evolves would be a headache. We decided it was easier to build a solution designed for this from day one, be able to maintain and improve on it over time, and tie it directly in with our back-end systems that manage developer keys, API access, and other management functions. All of this can be controlled from a single consistent user interface.
Oren Michels, CEO
Mashery
This seems like a feature provider, not a company. Where is there an exit for the investors? Weak concept and weak management team, signs of another bubble.
Does mashery handle invoicing / payment / collection?
I’m guessing not, but that would be a very useful (and valuable) thing to provide.
OK, I get the business plan, sounds great.
At the moment, I am working on a public developers API and your service seems like it could take the place of the authentication/throttling layer we were planning (in addition to the community/support features).
In the interest of boiling mashery down a bit:
– is it simply an API proxy?
– such that I would effectively have two DNS entries?
– does it provide HTTP caching?
– if not, does it at least allow the API to implement HTTP caching?
thanks, and looks promising!
@ Jonathan – Yes, we do. That functionality is nearly complete, and we agree that it is useful and valuable. That said, we believe that many APIs generate value for their providers even if access to the API itself is not directly monetized. As long as an active developer community grows, and the provider is able to manage access and ensure API usage is consistent with the provider’s terms and conditions, there are many APIs that will accrete substantial strategic value and significant revenue.
@ Brian – Thanks for so effectively summarizing Mashery’s strategy so cogently. I couldn’t have said it better myself. You build the API, and when it’s done, we have what you need to release it to the world right away.
To your specific questions:
- A key component of this week’s launch is our API proxy, although we have alternatives to proxying for larger clients who prefer a direct access solution
- You should not need any more DNS entries than you already have, if I undertand your question correctly. You are likely already sending your API calls to a separate domain, such as api.yourdomain.com. That domain would be redirected to us, and we in turn would access your API directly through a private DNS entry used only by Mashery. Should you ever decide to discontinue using Mashery, you would simply point the API domain to your servers or to another service provider.
- We do not currently provide http caching, but we have had several requests for that and expect to provide a solution for that soon. Meanwhile, there should be no issues with using other caching tools. Email us and we’ll work with you to figure out a solution.