Thursday, May 31, 2012

API Monetization: API Affiliate Network API + Google URL Shortener API

In my quest to understand the monetization opportunities via APIs, I’m studying the possibilites around tracking, and now monetization of content and URL’s served up via APIs.

The other day I considered wrapping URLs for another layer of metrics in your API, and today I’m thinking about how to evolve API monetization beyond advertising, defining entirely new API driven conversion events where both API owners and consumers, can realistically make money.

I first talked about an advertising network dedicated to APIs and developers last year, and everytime I come back to it in my Evernote list, I can’t help but consider using the Google Affiliate Network as an engine.

I don’t have any access to Google Affiliate Network (I submitted request), so all of this is speculative. But after looking through the Google Afffiliate Network API interface, it looks like I can pull both advertisers, publishers and events through the API-- so I’m envisioning two scenarios:

  • API Owners - As an API owner I could use the Google Affiliate network to define “events” that could occur via my APIs, and setup my API developers as “publishers”.
  • API Consumers - As an API consumer I could setup various APIs I use as “advertisers”, creating specific events for these APIs, and setup my own applications or sites as “publishers”.

In either case, API owners or API consumers could replace any URLs in content or URLs directly served up via APIs with a Google Affiliate Network generated URL with specific conversion events defined, then shortened using Google URL Shortener API.

This would create a layer of not just metrics, but conversion events that could be monetized. API consumers could choose from affiliate opportunities available on the Google Affiliate Network, and API owners could do the same, or define their own conversion events that were meaningful to their business goals.

These are just some original thoughts on API monetization using Google Afffiliate Network API and the Google URL Shortener API. Seems like there is a lot of opportunity monetize the data and resources flowing through API pipes, whether you’re an API owner or avid API consumer.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/K1gDPpKhc4M/

An API Could Be The Fancy's Kill Move Against Pinterest

Pinterest and The Fancy are locked in a deathmatch, if you hadn't heard? Compete wrote back in February that The Fancy was poised to take over a chunk of Pinterest's traffic with their new webstore. Fast forward 5 months, The Fancy has just launched an update to their iOS which includes the ability to purchase products from the mobile app with just one click.

Nice move! The Fancy is definitely an easier and cleaner looking site than Pinterest, and with a monetization move, The Fancy could gain even more market share against Pinterest.

Now if The Fancy wanted to seal the deal and put a death nail in Pinterest's coffin, they should launch an API, and make The Fancy a platform. Don't just open up API access to your content--open up API access to your new commerce layer as well.

Once you have this mapped out, deploy a well crafted suite of embeddable objects, like share and buy buttons, along with essential widgets--all with the commerce layer built in.

Developers and non-developers will make sure The Fancy becomes ubiquitous across the web, and because you chose to consider monetization, while making your platform play, and included developers in this model, the entire platform will be sustainable and outlast anything Pinterest can come up with.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/lqgDDF0PDHM/

Healthcare Imaging API

There is a new API edition to the healthcare industry this week. lifeIMAGE launched an API that can be used by developers of healthcare applications, to enable the secure exchange of medical images and related patient records.

Norman Young, President and CEO of ClearCanvas, said “We were founded on the simple belief that medical imaging informatics should be accessible to all. Now, using the lifeIMAGE API, users of our FDA-cleared diagnostic viewer will be able to instantaneously share images that are in front of them with any one.”

The healthcare is industry that is ripe for API adoption, so I’m always looking for “healthy” new API stories for the space--lifeImage API is perfect. You can find out more about the API at www.lifeimage.com/api.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/IfA5MKRp-NI/

Be a Feature in Other Platforms with an API

I talk with a lot of entrepreneurs in my travels to conferences, hackathons and online with my API evangelism. I get a lot of ideas pitched to me, asking me for feedback, and ultimately if I think their startup is viable.

I hear a lot of good ones, and bad ones. Even the good ones face an uphill battle to get noticed in an extremely crowded and noisy landscape. The one piece of advice I leave with all startups about how to get their web or mobile app noticed?

Develop an API!!

The one thing an API can do for your startup is allow your product to become a feature in other platforms. If you deliver only as a mobile or web app, you are leaving out numerous opportunities to become the next killer Facebook or Salesforce feature, or something smaller like a Wordpress add-on, but ultimately something that could make enough of a mark, that your startup could survive.

So when you are planning the feature list for your killer startup, make sure you consider an API, and the potential of becoming the next killer feature in an existing platform.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/MV2V0L4TcHo/

Provide Release Valves for API Rate Limits

In my effort to better understand API access, I’m studying how API owners control access to their APIs, with most recently being around Rate Limiting. The other day I asked, why do we limit API access for developers, and even explored rewarding developers for heavy usage.

As I continue to understand the impact of rate limits on developers it’s becoming clearer that for an API to successfully impose rate limits, you should also be offering rate limit release valves in the following ways:

  • Increase Request Form - There should be a formal, self-service way to request rate limits either for valid uses that you hadn’t considered bumping up against rate limit ceiling, or quite possibly for non-commercial purposes.
  • Utility Pricing - Providing a pay as you go model, where users meet the "courtesy limit", they can put in their credit card and pay for what they use above and beyond the default rate limit.

There are many points of friction for developers trying to integrate with an API. In my research, one of the ongoing complaints of developers regarding an API is around rate limits. Many of these complaints are directed at APIs who impose rate limits without any clear path beyond the default limits.

Google seems to be offering opportunities for developers to pay for use beyond their "courtesy limits", providing a form of release valve for developers concerns about API rate limits.  Google is providing these release valves for API services via their API Console, but only appear to available for a handful of services. 

While I’m still unsure about API rate limits in general, it seems clear that if you are going to limit, make sure and provide a release valve in some way, so developers understand what the options are when they hit the ceiling, and that there are opportunities to grow.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/Bu8qAt0nGTQ/

Wednesday, May 30, 2012

API Management Platform for Universities

I recently stumbled across the University of Washington’s Web Services area, where they are working to create a single place to learn about, discover and connect with various APIs that are available at the University.

As the home page says:

Web Services at the University of Washington is a method of getting important institutional data from and/or into your applications. Web Services are a way for applications or systems to talk to one another and does not usually involve human interaction.

I’m always trying to understand where the next wave of API growth might come from, and while the enterprise is definintely sitting on a treasure chest of information and resources, just waiting to be exposed via APIs--I think Universities might be in the same position.

As soon as Universities start realizing how many APIs they have laying around already, and understand the potential of launching new ones, they are going to have a massive API management problem.

I stumbled across UW APIs via a ProgrammableWeb update of 7 web services from the University. I started looking around further, and discovered there were 29 total APIs available at UW Web Services. I’m not sure why only 7 are listed at PW, but right there you start seeing slippage in the current API directory model.

Quickly invdividual schools are going to face the same problems Google has faced with its almost 100 APIs and need to standardize their management platform with:

  • Access - Usage of a healthy balance of keys and OAuth for accessing school and student data 
  • Discovery - Establish some sort of WADL or other discovery service that can feed not just a human directory but IDEs and other programmatic discovery. 
  • Explorer - Provide an API explorer so developers and even non-programmers can make calls against any API without writing code 
  • Billing - Establish some sort of billing layer, if only for making high volume users pay for access and pay for infrastructure--but also possibly opening up new revenue streams for universities

In addition to these areas, Universities will have to establish a common set of API building blocks that they will use across all departments, creating a consistent API area for developers to use while learning about and integrating with University Web Services.

With some proper planning and a little work, each University could setup a highly functional API strateg and management framework allowing them to efficiently manage not just dozens of APIs, but thousands across all areas of the University.

Think of the opportunities for students to build out much needed mobile and web applications around school information as part of class projects. The benefits of having self-service interfaces that individual departments can use to get the information they need, as well as for 3rd party vendors who need access to vital school data.

Next, would be to create a state and federal discovery layer on top of each University, allowing better oversight and interaction between government and Universities--but that will have to come later, we have a lot of work to do at each University before we get there.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/f1To-TCLYAI/

Twitter Rolls Twitter.com Back to a Server-Side Architecture

I recently stumbled across the University of Washington’s Web Services area, where they are working to create a single place to learn about, discover and connect with various APIs that are available at the University.

As the home page says:

Web Services at the University of Washington is a method of getting important institutional data from and/or into your applications. Web Services are a way for applications or systems to talk to one another and does not usually involve human interaction.

I’m always trying to understand where the next wave of API growth might come from, and while the enterprise is definintely sitting on a treasure chest of information and resources, just waiting to be exposed via APIs--I think Universities might be in the same position.

As soon as Universities start realizing how many APIs they have laying around already, and understand the potential of launching new ones, they are going to have a massive API management problem.

I stumbled across UW APIs via a ProgrammableWeb update of 7 web services from the University. I started looking around further, and discovered there were 29 total APIs available at UW Web Services. I’m not sure why only 7 are listed at PW, but right there you start seeing slippage in the current API directory model.

Quickly invdividual schools are going to face the same problems Google has faced with its almost 100 APIs and need to standardize their management platform with:

  • Access - Usage of a healthy balance of keys and OAuth for accessing school and student data 
  • Discovery - Establish some sort of WADL or other discovery service that can feed not just a human directory but IDEs and other programmatic discovery. 
  • Explorer - Provide an API explorer so developers and even non-programmers can make calls against any API without writing code 
  • Billing - Establish some sort of billing layer, if only for making high volume users pay for access and pay for infrastructure--but also possibly opening up new revenue streams for universities

In addition to these areas, Universities will have to establish a common set of API building blocks that they will use across all departments, creating a consistent API area for developers to use while learning about and integrating with University Web Services.

With some proper planning and a little work, each University could setup a highly functional API strateg and management framework allowing them to efficiently manage not just dozens of APIs, but thousands across all areas of the University.

Think of the opportunities for students to build out much needed mobile and web applications around school information as part of class projects. The benefits of having self-service interfaces that individual departments can use to get the information they need, as well as for 3rd party vendors who need access to vital school data.

Next, would be to create a state and federal discovery layer on top of each University, allowing better oversight and interaction between government and Universities--but that will have to come later, we have a lot of work to do at each University before we get there.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/RTK5r-jWbaI/

Tuesday, May 29, 2012

Twitter Rolls Twitter.com Back to a Server-Side Architecture

Twitter just rolled back their architectural approach for Twitter.com back to a server side implementation.

If you remember back in September of 2010, Twitter rebuilt Twitter.com to use a web application architecture that pushed all of the UI rendering and logic to Javascript running in the browser and consumed the Twitter API directly.

Now they are "taking back control" of their front-end performance by moving the rendering back to the server. They don't say whether they don't use the APIs at all, but I am working under the assumption that they abandoned them.

Twitter felt the API driven web application architecture broke new ground, offered a number of advantages, but it lacked support for various optimization techniques available only on the server.

I was excited to see Twitter go with the API driven approach, along other sites, like the FCC.  I hate to see them abandon it.

What does this say about an API oriented architecture?

Are we not ready? Are there are not enough tools for optimization, or the talent to deliver the performance necessary for Internet at scale via API driven architecture?  Or maybe there are other business reasons for stopping eating their own dog food and going back to a server side architecture?



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/PNUnhQGH-tU/

University Information Services with APIs

APIs are making information more accessible across many industries and sectors, but one area I haven’t seen a lot of movement, until recently, is at Universities.

Last month, Harvard openly licensed their library meta data and through a partnership with the Digital Public Library of America, made it available via APIs. But today’s story is more about APIs driving the operations side of higher ed at the University of Washington.

Under the Universities of Washingtons web services site, you can learn, discover and connect to 29 separate University APIs:

Its grest to see that the University is trying to create a single directory of all University web services, and even has an API suggestion service where students and faculty can submit and vote on ideas for new, useful campus APIs.

With the volatility of school funding, online learning and just overall competition in higher ed, Universities need to start noticing of the transformative powers of APIs, and how it can make University operations more transparent, accessible and nimble, and potentially even save money when it comes to empowering the students themselves to build interfaces for accessing vital University information.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/zU_9NgpKK40/

Why Do We Limit API Access for Developers?

I am putting a lot of thought into why we limit API access for developers.  I understand requiring keys to access APIs, and tracking who has access to your API, so you can understand how they are using it. What I don’t understand is why you’d want to limit API access.

By limit, I mean...here is an API, you get 100 calls, then no more! No option for paying, begging or pleading for more access. There are some APIs (I will evaluate specific APIs in the future), that have this approach, and it just doesn’t make sense to me.

Last year I touched on this subject with a post in ProgrammableWeb called, Should We Be Limiting Developers’ API Usage? Where I flip this model on its head and showcase two API providers, YellowAPI and ironically enough Qwerly (another story by itself), and how they were actually rewarding developers for more API usage.

I understand that in the early days, limiting access was a way to keep people from using their APIs too much, but I think in the era of cloud computing, that throttling as opposed to limiting is a better option. Let price control a developers API usage, and set that price at a level that is logical for this equation.

If your limiting developers from using your API, why even have one? It seems like you should sit down and re-evaluate your business model. I hope you don’t have other products that your customers can access, that at some point you cut them off and say, you can’t have anymore.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/sYAaK09kMMo/

Saturday, May 26, 2012

Wrapping URLs for Another Layer of Metrics in Your API

I’m documenting Twitter’s process of wrapping the URLs contained within tweets, using a shorter URL like t.co. I’m interested in understanding the opportunities around URL wrapping (aka URL shortening) as an API business strategy.

From an API business perspective, the reasoning for implementing URL wrapping as part of your API would be:

  • Saving Space - By shortening URLs you are reducing the length of any string that contains URLs, and in cases like Twitters, every character counts
  • Security - Twitter is actively combating URLs that carry malicious intent
  • Analytics - Each shortened URL provides a mechanism for tracking clicks on URL within content

Shold URL wrapping be something API owners adopt for all content served up via an API? Could every URL within content served up via an API be wrapped, allowing tracking of clicks through that URL--no matter where that content ended up living after it left the API?

Just some initial thoughts, but it seems that a comprehensive linking strategy could be established, bundled with a URL shortening service like Bit.ly, Google URL Shortener or a custom service--and provide a new layer of metrics that could be used to tell how your developers and their application users are interacting with the content you serve up via your API.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/VwyNwZoO2Hk/

Friday, May 25, 2012

Lack of Pinterest API is a Lack of API Business Strategy

Here we are going into June, and I still don’t see a publicly available Pinterest API. Jay Yarow wrote in Business Insider back in February, "Pinterest's API Is Coming Soon, And VCs Are Super Excited" and Adam Duvander wrote in ProgrammableWeb, "Pinterest API: Coming Soon or Already Here?".

There is also a reply to a Quora thread by Yashh Nelapati, Lead Engineer at Pinterest from May 2011, saying the API is 2-3 weeks away. It’s now a year later and there is no official API (there is a Rogue API).

Business Insider says, Pinterest fears having a "Twitter problem. Meaning that when Twitter released its API, it was still an immature company, allowing developers to build applications with features that it was missing--then Twitter matured, and it wanted to control its platform, it began adding building its own features and poaching from the Twitter API ecosystem.

So why not learn from Twitter and other APIs, and use the appropriate API building blocks to address this:

  • Branding Guidelines - Establish branding guidelines that clearly lays out what apps that use Pinterest API should look like
  • UI / UX Toolkit - Provide a UI / UX toolkit like Twitter Bootstrap that sets the tone for applications built on the API
  • Roadmap - Provide a real-time and transparent roadmap that developers can use to help keep their development efforts in line with Pinterest
  • Developer Framework - Establish a developer framework outlining opportunities for developers to become stronger members of API community, also introducing possible investment and incubation of most success or important features
  • Terms of Use - Establish a fair and equitable terms of use that protects Pinterests but acknowledges the commercial aspirations of developers
  • Events / Meetups - Establish a roadshow or network of meetups that brings developers together and makes them part of the Pinterest API community

These are just a few of the ways Pinterest could establish a solid business strategy for their API that would not only protect developer interests, it would establish the Pinterest API as an external research & development department, with a built in incubation component.

Pinterest has already missed out on a year of developers innovating on their platform. Why continue holding back innovation? Establish a flexible API business strategy that allows for you to learn from the mistakes made by Twitter, and become the platform VC’s are looking for you to become.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/LUhqdwARqDo/

The API Driven Life of Your Facebook Mobile App

One of the best ways to explain what APIs are to someone sitting next to me on the plane is to find something the user does every day, that is driven by an API, and explain how an API drives the functionality they take for granite.

I tend to look for industry specific examples if they are an accountant or stock broker, but the most common example I use, is Facebook. Facebook is technology everyone I meet has exposure with.

My story always starts with Facebook.com, and how the social networking website was built for people. People go to www.facebook.com and they see HTML web pages, that allow them to interact with the community.

Next I move to the Facebook application on their mobile phone. While the application is built for people to use, the application needs a way to talk with Facebook--in comes APIs. APIs are a way for other programs to interact with Facebook, providing a interface for developers to build applications that use Facebook.

When you first login to Facebook on your mobile phone, the applications makes a request to the Facebook Authentication API, and gives your mobile application rights to interact with your Facebook account on your behalf.

After your logged into the Facebook application on your mobile app, every action you take will make an API call. When you click on your news feed, update your status, look at photos or check-in to a place, they each represent a different call to the Facebook Open Graph API. The Open Graph API exposes almost every aspect of Facebook as a programmatic interface that applications can use, hence the name Application Programming Interface (API).

 

Most online technologies that you use everyday have APIs. Amazon, EBay, Facebook, Twitter and Google all have APIs, allowing developers to build applications on top of their businesses, turning their websites into web services.

With the grwoth of the smart phone and tablet markets, the number of, and usage of APIs are exploding, silently driving the mobile applications like Facebook that are part of your everyday lives.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/5Yd_-v3gkVg/

Thursday, May 24, 2012

Visions from the API Economy

I’m always looking for solid examples of how more and more of our every day world is being driven by APIs. Examples I can use to help explain APIs to every-day business folks.

I came across one example that will speak to many business executives today via an Apigee Innovator Spotlight on their client TradeKing. When asked about the vision of their API program Dan Raju CIO of TradeKing says:

We are one of the top-ranked online brokerages in the country, growing very rapidly. We manage people's assets, give them a set of capabilities to trade, and offer an extremely transparent pricing structure. However, we recognized that our customers’ demands for next-generation interfaces are rapidly changing, and our API helps us stay in front of that. We anticipate that in the next phase, the API will be a meaningful revenue driver for us. It is already opening us up to new markets. We will continue to develop our own platforms on the API and incentivize and engage our development partners. At the end of the day, it’s all about delivering value to our customers, and the API will continue to help us drive increased value at an accelerated pace.

Raju hits on all the best of the API buzzwords including transparency, rapid change, meaningful revenue, open to new markets, and delivering value to end-customers.

I feel TradeKings vision of their API program, speak to larger visions of the API driven economy we are now immersed in, and provide a great example we can reference when helping other companies not just understand what an API is, but the imperative for their companies to embrace APIs and actively join the API economy.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/dK1PX4RA-MI/

Developer Insights Into Facebook Open Graph API Usage

Facebook provides an interface for Open Graph API developers to better understand how users are interacting with content via their applications, called Insights.

With Insights you can monitor the number of your unique users that are seeing and accessing a Facebook authorization dialog, number of unique users publishers stories through Open graph as well as viewing and clicking on those stories.

While the number of users clicking, viewing on stories is very cool, I’m interested in their stats regarding the authorization dialog. Insights provides data on how many times people access your dialog authorization, with the number of acceptances, while also breaking down the number of views, acceptances into a corresponding conversion rate.

If your authorization dialog prompts users for different permission sets, you’ll also see a breakdown of the impressions, accepts and CTR for each one, showing you the rates at which people accept and reject different permission sets--helping you to identify the most optimal permission set for your authorization dialog, which will directly help increase user installs for your app.

This kind of insights for developers is critical, helping them understand the level of engagement with users and build a more effective Auth Dialog flow, which could make or break an applications Facebook Open Graph integration and adoption.

Providing developers with analytics to evaluate their users API usage is so valuable, I wonder if I can find any other examples of this granular type of OAuth reporting with other APIs or from API service providers like Apigee?



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/AP4cb0ee_3U/

Wednesday, May 23, 2012

Google Updates the API Explorer

Google just released an update to their API Explorer.

Some of the new features include:

  • Indexed history of API calls
  • API request body editor
  • Search box for search APIs and methods
  • Indicator showing which methods require authentication

The Google API Explorer now supports two dozen Google APIs, up from only six when they first launched.

Google’s continued investment in their API explorer, which makes APIs not just easier to use, but more accessible to non-developers, really shows that an API explorer has become an essential API building block.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/Rm8Qs14qiOY/

Nike Sustainable Products Index API

Nike is working on a new API as part of their Nike Better World initative. The API provides access to a materials sustainability index, which evaluates the environmental impact of materials used by manufacturers.

The scoring system evaluates the environmental impacts of materials used in products using a combination of materials-specific data, covering areas such as Chemistry, Energy and Greenhouse Gas Intensity, Water and Land Use Intensity, and Waste.

The Nike Materials Sustainability Index API is only in alpha stage right now, and is undergoing for a peer review process with Duke University. You can follow their Nike Maker’s Blog to get more information on the initiative and get notified when the API will be available to the public.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/eRXHrM2O0Q8/

Tuesday, May 22, 2012

How Are We Going to Track Private APIs?

Image Credit - Wiki Noticia

Adam Duvander (@adamdreported at ProgrammableWeb today that they rolled over 6,000 public APIs in the directory. The pace at which companies are launching public APIs is accelerating, with the last 1,000 added in just 3 months.

Any of us in the space knows that this is just the tip of the iceberg, and Adam acknowledges that internal API usage is a major factor in API growth. While public APIs get all the major press, there are many private API initiatives that won’t see the light of day.

So my question is, how are we going to track on the growth of private APIs along with public APIs? Since mobile app development is such an important piece, can we count mobile apps produced by a company? Can we count on API service providers to start reporting on this data?

I don’t have the answer. It is something I think we need to figure out, not just so ProgrammableWeb can have its finger on the pulse, but there is an ever increasing amount of business and personal resources flowing through these API pipes, we need to have an understanding of where these API pipes are laid, which industries, etc.

Much like the rollout of fiber in the late 90’s, we are going to see massive API rollouts, without much oversight and map of where these virtual pipes are. I’d like to hear more about how we can work together to build a map of the back-end of the new API driven economy.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/37GFlhAmxY0/

Saturday, May 19, 2012

Find Your Hackathon Venue with EventUp

I am going through all my notes from organizing the CityGrid Los Angeles Hackathon and trying to publish as many stories as I can, about how I planned and organized the hackathon.

One service that was a catalyst for the event occuring, was assistance from EventUp. EventUp is a service that assists event venue owners in finding people to rent their space, and in turn can help you find the ideal location for your hackathon. 

Tony Adam (@tonyadam) the owner of EventUp emailed me one day after I had submitted a request via eventup.com for more information on venues for my Hackathon in the Los Angeles area. He offered to help make sure I found the right location.

After a couple days he helped me secure CoLoft which was the best location for the hackathon imaginable. It was accessible, had great layout with tables, good wifi and the staff was extremely helpful.

EventUp isn’t in all markets yet, but if you’re planning a hackathon I recommend talking with Tony at Eventup, and seeing if they have the right location for your event.



from API Evangelist http://feedproxy.google.com/~r/ApiEvangelist/~3/XvysJl66CLY/