The Web Development Series is supported by Rackspace, the better way to do hosting. Learn more about Rackspace’s hosting solutions here.

In our ongoing series on APIs, we’ve covered whether to offer an API and how to get people using it. Now, we’re delving into one of the most important questions an API-offering company can ask: free or paid?


Paid Is the New Trend


Augusto Marietti founded Mashape, a marketplace for building, distributing and hacking with APIs. He says that while the majority of APIs are now free, that trend is changing.

“I think that the monetization of APIs in 2011 is like the monetization of search back in 1999. … For example, Twitter started to charge [for use] of its data via APIs using Gnip as a reseller. Newer startups for which the API is the product, like Twilio or SimpleGeo, are coming out regularly. These startups are making money out of their APIs — a lot.

“The best bet is to keep a freemium model, so that all of your developers can try your API and use it for a while before opening up their pockets. You will see more and more startups having an API not only as a distribution mode but as an additional revenue stream, too.”


Cover Your Costs


Guillaume Balas is an executive at 3scale, which offers full-featured API management and monetization tools. He says, “At 3scale we believe this very much depends on what companies want to achieve with their API and who is going to be their users/customers. Not charging for your API access has definite advantages, such as improving branding and online presence and accelerating developers’ adoption … But don’t neglect the economics of your API business and the costs (infrastructure, management, maintenance, support, communication and promotion) associated with it.”

He adds, “Brand equity is great, innovation is key. But cash is king — and companies must at least cover their costs.”

Dimitri Sirota, an executive for Layer 7 Technologies, which offers its own suite of API management tools for the enterprise, says you should do both. “Have your API be free to start with and ask people to pay for higher grades of SLA, premium functionality, enhanced support, etc. Maybe offer a revenue share,” he says.


Consider a Hybrid Model


Shanley Kane works on the product team at Apigee, a company that offers a range of API tools for developers and software companies. She says, “The choice to charge for an API or offer it for free needs to be connected to your business goals and objectives. For many companies, charging for data and services exposed through an API makes sense. APIs provide a better way for customers to integrate and innovate and are an important monetization channel.”

However, for companies that open an API to expand into new platforms like connected and mobile devices, or to encourage third-party innovation, she doesn’t recommend a paid model. “For these companies, charging for access just adds a barrier to entry,” Kane says.

Kane also suggests a free-paid hybrid model, wherein independent devs get free access to build apps and larger partners pay for higher rate limits and additional support.


Make the API Part of Your Business Plan


Oren Michels is Mashery‘s CEO. His company does API management and strategy for more than 100 brands and 25,000 applications. He says the API should be an extension of the company’s overall business model.

“If your business model is to sell TVs, you want it to help you sell more TVs. If you are traffic/ad based, you want to generate more traffic looking at your ads. If you happen to be in the business of selling data — a big ‘if,’ since few companies are — then by all means charge for your API. More accurately, charge for access to your data, which may include either charging more for it by API or including API access as part of the overall subscription.”

Do you have other tips for pricing an API? Let us know in the comments.


Series Supported by Rackspace


rackspace

The Web Development Series is supported by Rackspace, the better way to do hosting. No more worrying about web hosting uptime. No more spending your time, energy and resources trying to stay on top of things like patching, updating, monitoring, backing up data and the like. Learn why.

Image based on a photo from iStockphoto user alxpin


More Dev & Design Resources from Mashable:


Ruby on Rails: Scaling Your App for Rapid Growth
HOW TO: Transfer Your Blog From WordPress.com to WordPress.org [VIDEO]
A Beginner’s Guide to Integrated Development Environments
10 Chrome Web Apps to Check Out
10 Tools for Getting Web Design Feedback

Images courtesy of iStockphoto user alxpin, enot-poloskun, AUDINDesign

More About: api, api management, api series, APIs, developers, web development series

For more Dev & Design coverage:

The Web Development Series is supported by Rackspace, the better way to do hosting. Learn more about Rackspace’s hosting solutions here.

Once you’ve decided to build and distribute an API, how do you persuade developers to use it?

Our panel of API experts has returned to reveal tips and best practices for promoting your API among third-party developers, and they’ve got some great ideas for helping you achieve critical mass.

Guillaume Balas is an executive at 3scale, which offers full-featured API management and monetization tools. He says, “There is no secret sauce that guarantees API success. However, there are some must-have best practices to follow … But even having these best practices in place, there are still many other dimensions to consider.”

For example, Balas asks, what kind of recognition does your brand already have? What kind of buzz will you get from an API launch? How much are you willing to invest in promoting your API and supporting its users? How fast will you act on feedback from your API users? The answers to questions like these will determine the size of your API’s userbase.


Make It Worth Their While


Oren Michels is Mashery‘s CEO — his company does API management and strategy for more than 100 brands and 25,000 applications. He reminds those with APIs to remember that the API itself necessitates a symbiotic relationship. To get devs onboard, he says you must offer developers something meaningful — usually that’s fame or fortune.

“What is in it for a developer to work with you? Does it provide direct economic benefit (always nice) or indirect benefit (often nicer), such as making an app they have built better and therefore more likely to make them money? Celebrate successful developers as the heroes they are. Remember that if it’s all about you, they have no reason to build things for you,” Michels says.

He also notes that making terms and conditions reasonable and allowing devs to actually make money from your API is a given. A good rule of thumb: Would you sign your own T&Cs if you were a dev? If the answer is no, go back to the drawing board.


Make It Really Easy


Shanley Kane works on the product team at Apigee, a company that offers a range of API tools for developers and software companies. She says the key to mass adoption of your API is making it as simple to use as possible.

“Developers use APIs that are accessible, follow REST design principles and lower the barrier to entry,” she says. “Simplicity is a differentiator, and complexity kills adoption. Use a simple design, version intelligently, have good documentation and be responsive in support forums.”

Michels is in agreement on that score. “You have to make it easy, ” he says, “with lots of communication and documentation. Code samples. Active forums where questions are answered quickly and accurately. You want to be the path of least resistance to solving their problem when and how they want to solve it.”


Get Into the Community


Kane also notes it’s important to be part of the community of developers you’re trying to build. “Promote the awesome apps devs build,” she says. “Go to hackathons or hold your own. Tell developer press about what you’re working on. Have contests. Stay in touch on developer forums and online communities. If no one knows about your API and the great things they could do with it, no one will use it.”

Dimitri Sirota is an executive for Layer 7 Technologies, which offers its own suite of API management tools for the enterprise. Accordingly, he comes to the table with a different perspective from that of the typical web startup developer.

For enterprise (and other) APIs, Sirota recommends a few tricks for jump-starting API usage. If you have the resources, you could hold contests to find and reward the best apps built on your API or organize dev camps, for example.

But Sirota also points out the basics: You’ve got to “make the tools readily available, promote novel applications built on the APIs, advertise APIs … and help developers make money from APIs” as part of your community-building plan.

Do you have other tips for getting devs to use your API? Let us know in the comments.


Series Supported by Rackspace


rackspace

The Web Development Series is supported by Rackspace, the better way to do hosting. No more worrying about web hosting uptime. No more spending your time, energy and resources trying to stay on top of things like patching, updating, monitoring, backing up data and the like. Learn why.

Image based on a photo from iStockphoto user alxpin


More Dev & Design Resources from Mashable:



Ruby on Rails: Scaling Your App for Rapid Growth
HOW TO: Transfer Your Blog From WordPress.com to WordPress.org [VIDEO]
A Beginner’s Guide to Integrated Development Environments
10 Chrome Web Apps to Check Out
10 Tools for Getting Web Design Feedback

More About: api, api management, api series, APIs, developers, web development series

For more Dev & Design coverage:

This post originally appeared on Dyn.com, a world leader in managed DNS, powering the best brands on the web including Gowalla, Mashable, Twitter, Wikia and more. Follow @DynInc on Twitter.

APIs are a hot topic among developers these days. Companies ranging from startups to large enterprises are offering them, and APIs have, to an extent, become the lifeblood of interdependent web services.

So how do you decide whether or not your company should offer an API?

To deliberate this question (and to learn about some of the tools available for offering APIs), we’ve turned to a panel of experts whose daily business is the building, distribution, management and monetization of APIs. Here’s what they have to say about choosing whether or not to offer that kind of access in the first place.


To API or Not to API?


Oren Michels is Mashery‘s CEO; his company does API management and strategy for more than 100 brands and 25,000 applications. He told us in an email, “”Ultimately, the API is a means for growing your business — and I use the term ‘business’ to include whatever your mission is, be it traffic or commerce or a nonprofit improving the world or a government entity serving its constituents — faster and larger by virtue of engaging with others. Understand how and why your API can do that and you will be successful.”

Shanley Kane works on the product team at Apigee, a company that offers a range of API tools for developers and software companies.

She says the first thing to do when considering building an API is to identify the goals and audience for that API. “This will inform every step of the API strategy,” Kane says, “from design to go-to-market. Companies open APIs for many reasons — to encourage developer innovation, monetize data, connect with partners or get to mobile and connected devices. Setting out with a clear objective that is tied to business goals and has a defined target market — whether large partners or independent developers — is critical to successful API programs.”

Kane also says to keep an eye on your competitors. APIs are products like any other, and the current ecosystem of platforms and services is vast and intricate. If your API is meeting the same need as a competing product, Kane says you have to ask yourself what makes your service or your API different — “How will your API stand out and win?”

Augusto Marietti founded Mashape, a marketplace for building, distributing and hacking with APIs. He gives decision makers a thorough checklist of questions to consider when thinking about whether or not to offer an API. Take these questions into early meetings and make sure each one is thoroughly answered before you move forward.

  • Do you want to have your API as a standalone product or an extension of your service?
  • Are you targeting the consumer or enterprise world?
  • Do you want to make money out of that or just see third party devs building on top of your platform to expand your service?
  • Who is your customer?
  • How much do you think you’ll need to scale?
  • How much does it cost to you?
  • What is your goal one year from now?

Dimitri Sirota is an executive for Layer 7 Technologies, which offers its own suite of API management tools for the enterprise. Accordingly, he comes to the table with a different perspective from that of the typical web startup developer.

He says companies should consider whether “the benefit of opening up my data in terms of reach and revenue outweigh the risk and cost.” He also cautions larger companies to fully define which department or specific personnel will “own” the product. He says to start out with a clear picture of your long-term goals — why are you offering an API? Is it for “revenue, retention or reach?”

Finally, if you’ve decided that the product in and of itself is a good idea, Kane says you have to plan for money and personnel. “Successful APIs need care, feeding and love,” she says. You must determine if your company is willing and able to devote the resources needed to build a successful API team and program, which includes the the need to “adapt the API and respond to user feedback, employ marketing resources to get the word out, and hire a community manager or developer advocate to make sure developers are taken care of and getting what they need.”

And while you might not need or plan to make money from your API (more on that in later posts), monetization discussions should occur early on, Kane says. “It’s very important to determine if monetization is a main goal of your service and if so, how you intend to charge or benefit from it. Offering a free service, then charging for it later, can have negative community backlash, so monetization is important to think about early and often. And if you decide to go free and open, identify the business metrics for it and how it fits into your business model.”

Michels also added that, when considering your API options, you need to consider the different types of devs that may be using it. “There are three major developer audiences for APIs: internal developers, second-party partners like biz dev partnerships or contracted outside app developers or affiliated companies, and third-party independent developers who may be developing new innovations that the API provider won’t even know about … Each audience has different needs and presents different opportunities, and you may want to address a few major second-party partners’ needs first before opening it up to a broader developer community.”


The Best Tools for the Job


Of course, our experts all work for companies that specialize in API management, so you’d likely be in good hands going to any of these companies when offering your own API. But we also asked them for basic advice on the kinds of tools you’
ll need to use and understand when building and managing an API for your company or service.

Sirota says, “You need an API proxy, a gateway to regulate what APIs get exposed to whom and when. The gateway is where you define the security policies, SLA controls and any integration/data mapping requirements. You also need API monitoring and lifecycle management … to address versioning of APIs and delivery of APIs across development, test and production. You also need visibility into usage.”

Finally, Sirota adds that you’ll need to create a developer portal of some sort. “This is the developer-facing piece, and it addresses all the developer onboarding, plan management, information discovery about the APIs, etc.”

Kane recommends GitHub as “a great resource for tracking issues, sharing code and documenting your API.” She also says that having clear and accessible documentation is “essential” for developer onboarding, and she recommends Google Groups for communicating with third-party devs using your API.

Kane says companies should be sure to get their APIs listed in ProgrammableWeb’s directory, and she recommends checking out Stashboard, an open-source status dashboard for APIs.

Stay tuned for more posts on getting started with offering APIs. And in the comments, let us know your own recommendations for offering APIs.


Interested in more Development resources? Check out Mashable Explore, a new way to discover information on your favorite Mashable topics.

Image based on a photo from iStockphoto user alxpin

More About: api, api management, api series, APIs, business, developers, Web Development

For more Dev & Design coverage:

LinkedIn has announced that it’s opening its developer platform, including its faster JavaScript APIs and customizable plugins, to all developers.

LinkedIn first released its original developer platform in 2009, complete with a set of APIs for letting third-party applications integrate aspects of LinkedIn in their apps. Still, its platform lacked certain features like OAuth 2.0 and advanced Javascript API support, something the company has been testing for the past few months.

The new LinkedIn Developer Platform and website make these APIs available to anyone who wants to use them. LinkedIn also opens its new platform for plug-ins, including the “Sign in with LinkedIn” button and the LinkedIn Share buttons you see on Mashable’s business and marketing stories. There are also plug-ins for member profiles, company profiles and a Recommend button that lets users recommend your products through their LinkedIn network.

The developer platform has also been overhauled with improvements under the hood. It includes a new Javascript framework that “loads significantly faster,” as well as support for SSL and improved support for OAuth. The website has also been simplified to make it easier to get started with LinkedIn’s APIs and plugins.

More About: api, developer, developers, javascript, linkedin, LinkedIn Developer PLatform, LinkedIn Platform, OAuth 2.0

For more Dev & Design coverage:

Pure play Twitter clients — apps like Echofon, Twidroyd and UberTwitter — got a sharp slap on the wrist today from Twitter platform chief Ryan Sarver.

In an API announcement post, Sarver finally made clear what third-party developers have known for months: The company does not want developers to make Twitter clients any longer.

Sure, you can make a Twitter analytics tool like Klout or a Twitter-integrated CRM platform like HootSuite. And the company loves it when startups like Instagram and Foursquare let their users plug in their Twitter accounts.

But if you’re thinking about making an app that displays and sends tweets, Sarver and company suggest you think again. Especially if that app has a different look and feel or uses different terms than Twitter uses itself. In other words, Twitter wants devs to build apps that use Twitter, not Twitter apps.

So why is Twitter cracking down — at least verbally, for now — on apps that look like and function like but aren’t Twitter?


Twitter’s Official Position on Third-Party Apps


Sarver on stage at Twitter’s developer conference, Chirp.

For some time now, developers have been asking Twitter for clarification on how they can avoid getting in Twitter’s way when building services on Twitter’s API. When Twitter decided to make “official” mobile and desktop apps in the spring of 2010, many third-party shops that had been using the API got burned badly; and nobody wants to repeat that performance.

What Sarver said to developers today was direct: If you don’t want to get burned, don’t build pure-play Twitter clients. And if your app displays and sends tweets, make sure it looks and feels like Twitter.

“Developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience,” he wrote.

“The answer is no.”

Twitter expects that it will be most consumers’ client — that means it wants to be the only app users interact with on mobile devices, personal computers, tablets, etc. And as of today, Twitter’s official apps are used by 90% of Twitter’s users.

However, Sarver noted, “If there are too many ways to use Twitter that are inconsistent with one another, we risk diffusing the user experience.”

How important is it to consumers that tweets look like Twitter? Sarver argues that the average end user will tend to be “confused” by changing UIs across various apps. He maintains that not only the design but also the core functions need to be the same across all Twitter apps.

“For example,” he writes, “a number of third-party consumer clients use their own versions of suggested users, trends, and other data streams, confusing users in our network even more.”

Sarver says that users might be confused by terms such as “like” and “comment” rather than “favorite” and “reply.” These distinctions may seem trivial to Twitter power users, but Twitter staffers say these little things mean a lot.

Twitter corporate communications staffer Jodi Olson wrote to us in a separate e-mail, “Our own research indicates that people get confused when the experience isn’t consistent, so we’re taking steps to ensure users can interact with Twitter the same way everywhere.”

A more egregious issue has been several apps’ violation of the Twitter API terms of service in ways that violate Twitter users’ privacy. Of these transgressions, Sarver writes, “Twitter has to revoke literally hundreds of API tokens [and] apps a week as part of our trust and safety efforts in order to protect the user experience on our platform. ”

On the other hand, Sarver gave a sort of whitelist of apps the company feels is using the API appropriately and in ways that make good business sense for both parties. Publisher apps like SocialFlow, curation apps like Sulia, real-time data apps like Klout, brand-focused apps like HootSuite, and “value-added” apps like Foursquare all got a hall pass.

But conspicuously missing from the list were clients such as TweetDeck, the UberSocial family (which includes UberTwitter and Twidroyd), DestroyTwitter, Plume (formerly Touiteur), PowerTwitter, TwitBird — all the apps that give consumer-level Twitter users a slightly different user experience without adding too many bells and whistles.


App Makers’ Initial Backlash


Laura Fitton speaking at Chirp.

Understandably, not every third-party dev has been thrilled with Twitter’s announcement. In an e-mail discussion with Laura “Pistachio” Fitton, founder of Twitter app marketplace OneForty, Fitton took the side of the 750,000 apps that make up the Twitter ecosystem.

“Twitter is full of genuinely earnestly awesome people who want to do the right thing,” she wirtes, “but it has resolutely failed to create the conditions for real business success on their platform.”

When it comes to business success, Twitter responds that the kinds of apps it censured today aren’t the kind that would be most likely to turn a profit, anyhow.

“We outlined what we see as the top five categories of business opportunities for developers,” wrote Olson, “and explained that we do not think that building mainstream consumer third-party clients is one of them.”

As for the different UIs between official and non-official Twitter apps, Fitton objects to Sarver’s rationale. “There’s enough confusion just switching between the various [offi
cial] Twitter apps — they all have UI inconsistencies.

“This argument was not at all convincing.”

On the one hand, we’ve seen users flip out and come to some pretty daft conclusions over relatively minor UI changes. Then again, if users like one Twitter “skin,” should they really be forced to give it up just because other users are “confused” by its knobs and buttons?


How Third-Party Apps Can Still Succeed


Identi.ca founder Evan Prodromou and Loic Le Meur at Chirp.

We spoke on the phone with Loic LeMeur, founder of Seesmic. During the Chirp debacle, when many app developers felt similarly betrayed, LeMeur spoke with a positive message that devs could still find success by creating diverse and valuable services that included but did not solely rely on Twitter’s API.

His main message to third-party devs today was simple and common-sense: Communicate, cooperate and adapt.

“There are two types of Twitter apps,” he said, “the ones Twitter likes and the ones that are competitive and don’t have good communication with them.

“We’ve been talking almost daily with Twitter… We’ve been very open with our roadmap.” While he says the startup never directly asked Seesmic to make any changes to the product, he said, “They know what we’re building, and they have no concerns.”

LeMeur notes that Seesmic has two factors that keep it out of Twitter’s way: support for other services (such as LinkedIn and Facebook) and a focus on enterprise and professional users.

“Twitter can’t do what we’re doing; Twitter will never support Facebook pages. In that way, we don’t compete at all,” he said.

We discussed some of the apps that do aggressively compete with Twitter, which is an odd proposition in itself. Think about it: Why would you build an interface for another company’s platform, then attempt to divert traffic and ad revenue to your interface, all while using the other company’s underlying service?

“Competing with your number one partner is a little dangerous,” said LeMeur, “and Twitter doesn’t want that to happen.”


How We Got Here & What Comes Next


Twitter co-founders Biz Stone and Evan Williams on stage at Chirp.

Back in 2007 when Twitter first opened up its API, the company was a model of what the social web was supposed to be — a collection of web services rather than websites — and its founders were lauded for their open approach to their own technology and evolving business model.

At the time, co-founder Biz Stone said, “The API has been arguably the most important, or maybe even inarguably, the most important thing we’ve done with Twitter. It has allowed us, first of all, to keep the service very simple and create a simple API so that developers can build on top of our infrastructure and come up with ideas that are way better than our ideas.”

We’ve certainly come a long way since those days. Twitter has already adopted many of the ideas third-party devs brought into the system. For example, the impressive interface of the “New Twitter” felt more to us like a really great third-party app than anything else. And Twitter’s mobile apps, which were a boon to overall Twitter usage, were informed and inspired by existing third-party apps, too.

But as the company continues to refine its product and search for its revenue, it’s closing the door to apps that thrive on its API while stealing its traffic.

Even the most optimistic developers, folks like LeMeur, for example, have had to struggle to keep up with Twitter’s shifting actions and attitudes. “I wasn’t expecting such dramatic changes,” said LeMeur, “but instead of complaining, I have to adapt to it.”

While Twitter wouldn’t comment on what might happen to some of these pure-play, competitive Twitter clients in the future, the company is a business, and its API is intended to help the business grow, not to make a charitable donation of Twitter’s userbase and technology. It’s fully conceivable that Twitter could revoke API access for apps like these in the future.

We’ll be keeping an eye out for any possible fallout from Twitter’s announcement today; in the meantime, take to the comments section to let us know how you feel about this situation.

Lead image based on an illustration from Flickr user matthamm.

More About: api, developers, laura fitton, loic lemeur, oneforty, pistachio, ryan sarver, seesmic, third party, twitter, twitter client

For more Dev & Design coverage:

Recently, API products company Apigee rolled out Apigee To-Go, a free tool for building an API console, classing it up with a slick UI, and embedding it wherever your developers are.

This new tool gives developers a DIY approach to offering brand-cohesive, usable API interfaces. Devs can create customized API Consoles themselves, skin the consoles to match existing branding, and then embed the console on their own sites. And all of these sweet features are free of charge.

Altogether, Apigee says their consoles can help you get your third-party devs from exploring the code to working with the code much faster. And all it takes from you, the platform provider, is three relatively simple steps: Describe the API, create the console’s look and feel, and embed the console using iFrame.

Web companies releasing APIs is a huge part of the developer ecosystem right now.

At Mashable, we preach about the necessity of APIs and laud innovative ones. And when possible, we try to spread the good word about tools for building APIs.

Apigee’s API Console made its debut last year; it was the company’s attempt to restructure how devs learn their way around a new API. The console, as Apigee staffer Shanley Kane writes, “lets developers view the full surface area of an API, authenticate in seconds, easily view API requests and responses, dig into errors and share their results.”

The consoles also let devs share snapshots of a request/response pair; Kane says this feature “makes debugging social and facilitates communication between the API team and its developers.”

Apigee’s custom-made consoles are used by companies like Twitter, Facebook and Salesforce. Apigee To-Go is the company’s way of giving DIY console-creation tools to developers to use on their own projects and sites.

Already, Etsy, Paypal and SoundCloud are using Apigee To-Go-built consoles for their own APIs.

Here’s a look at SoundCloud’s API console:

Other features include handling OAuth 1.0 and 2.0 and basic authentication, because, as Kane writes, “Authentication schemes like OAuth slow developers down.”

Let us know what you think of this product — and API consoles in general — in the comments. Will you be giving Apigee To-Go a shot?

Image based on a photo from iStockphoto user alxpin

More About: api, api console, apigee, developers

For more Dev & Design coverage:

Uber trendy mobile photo sharing startup Instagram is fast-approaching 300,000 photo uploads per day and closing in on 2 million members. It has also just released its API in private beta, according to an announcement on the startup’s blog.

The Instagram API will give selected developers access to the startup’s data and allow them to incorporate Instagram photos within their own applications. This marks a significant move by the startup; the decision will open up photos and user data, once locked down to the iPhone, to more web and mobile services and potentially spawn a new wave of user growth.

Interestingly enough, the Instagram API news follows Picplz’s public beta release of its API just hours earlier.

“Although we’re excited by the growth we’ve seen, we feel that the first step to creating a lasting company is to work with the many talented developers out there in the world,” writes CEO Kevin Systrom on the release.

Systrom assures app users that they will maintain ownership and privacy control of their images, saying that Instragram is granting access on an invite-only basis to ensure users’ photos stay protected.

“We’ve taken a close look at how to best protect your images and data while enabling developers to build cool stuff,” says Systrom. “We’d like to make sure that the people we do let in create quality apps that increase the aggregate utility of the ecosystem.”

With nearly simultaneous API releases, Instagram and Picplz have created a new battlefield and are now fighting for developer attention. Instagram’s API remains private while Picplz’s is public, which gives the Mixed Media Labs startup a marked advantage over the competition.

More About: api, developers, instagram, mobile photo sharing, picplz, trending

For more Dev & Design coverage:




MusiXmatch, a provider of digital lyrics solutions, announced at Midem 2011 new partnerships with BMG, Kobalt, Universal Music Publishing Group and Sony ATV Music, making musiXmatch the largest authorized lyrics database in the world, according to the company.

MusiXmatch, now replete with 5 million lyrics, is today launching a commercial beta that will let developers legally integrate lyrics into their applications.

In a statement, musiXmatch claims to be the only lyrics API to fully offer international rights management.

“The search term for lyrics drives more traffic than any other term on Google,” says Max Ciociola, CEO and founder of musiXmatch. “MusiXmatch gives developers the lyrics that they need to create deeper and more engaging online music experiences.”

The online lyrics space has existed in a rather shady area for the large part; the quality of lyrics can be spotty, and often they are presented sans rights. MusiXmatch’s latest partnership — and newly launched commercial API — should prove to be valuable for users seeking better-quality, legal content.

Photo courtesy of Flickr, jayneandd

More About: api, developers, midem-2011, music, musixmatch




Google has taken the next step to expanding goo.gl, its URL shortener, and integrating it into third-party apps with the launch of the goo.gl API.

The new API, like Google’s URL shortener, is rather straightforward. It gives developers the ability to use goo.gl to shorten or expand their URLs and to retrieve URL history and analytics.

“You could use these features for a wide variety of applications, enabling behaviors ranging from auto-shortening within Twitter or Google Buzz clients to running regular jobs that monitor your usage statistics and traffic patterns,” Google’s Ben D’Angelo said in a blog post announcing the API.

What does the launch of the goo.gl API mean? While URL shorteners may not be terribly sexy, they are becoming a big business, one dominated by Bit.ly. Goo.gl’s URL shortener could siphon off users with the API. Its integration with Google’s products, spam protection and speed could make it a desirable alternative for developers looking to speed up their apps.

More About: api, Goo.gl, Google

For more Dev & Design coverage: