We want to build better tools for API developers. Will you help? »

Apigee constantly strives to better serve the needs of developers and to that end, it’s time for us to conduct a usability review of our existing toolset.

If you have spent time making an app talk to an API, and can come by our Palo Alto offices next week, then we'd love to hear from you:

https://www.surveymonkey.com/s/KZH96KW

If you are selected, you’ll get a $150 AmEx gift card to help offset travel expenses (and a lifetime of gratitude from developers everywhere).

Usergrid is now part of Apigee »

I'm excited to announce that Usergrid is now part of Apigee.

Almost every mobile app needs back-end services to store and manage users, data and events. But powering mobile apps from the cloud is a hard problem, requiring a rich set of easy-to-use features for managing users, delivering applications objects and data, and analyzing usage and tracking key metrics.

A look at the BlueVia Developer Platform »

BlueVia, a global developer platform initiative of Telefonica, has partnered with Apigee to provide the BlueVia API console for developers to explore and test their APIs.

So we asked them to sit down with us to tell us a little about BlueVia. In this video, BlueVia's Dan Appelquist and Jose Valles discuss the BlueVia Platform with Jeremy Perlman of Apigee.

Tune in to learn what BlueVia is, how the platform provides access to Telefonica's assets and helps developers take apps, web services, and ideas to market.

And it's BlueVia's first birthday and they're celebrating by giving developers a chance to win a MacBook Air and Samsung Galaxy Nexus. Check the BlueVia blog for details.

BlueVia Developer Platform

The SMSified REST API Explorer »

Voxeo Labs, the creators of SMSified and other innovative communications services and technologies, has partnered with Apigee to introduce the new SMSified API Explorer!  Developers can explore and experiment with the SMSified REST API without writing a single line of code! Get started with adding inbound and outbound SMS text messaging to your application today.

In this video, Chris Matthieu of Voxeo labs walks you through using the API Explorer to interact with SMSified's SMS REST API.

SMSified API Explorer

Two Ton API client:  creating a generation of car hackers »

Aside from curb weight and operating speed - there's not a lot of difference between an iPhone and a fine automobile.  Both are at their most innovative when people drive them with APIs.

Why? See Brian Mulloy's (@landlessness) O'Reilly Detroit Ignite session - "Two Ton API client."  Both a talk track and the slideshare are below. And drive carefully...

Welcome to Apigee! »

Today we've changed the name of our company - from Sonoa Systems to Apigee Corporation. Sonoa Systems' API infrastructure platform is now Apigee Enterprise and the Apigee tools platform you know will remain free.

This company was started with the vision that the web would be mostly driven by web services. And this would bring new opportunities and challenges - business and technical.

It's happening with APIs - driven by an explosion in mobile, social, and cloud. What started on the web has become part of enterprises. Companies of all size are opening APIs to reach customers beyond the browser.

One year ago we launched our free Apigee service for developers using APIs. Today we are putting all our strength behind one brand and product line-up - Apigee Free, Premium, and Enterprise. Premium is in private preview today, and you can sign up for an invite to check out new features for providers like OAuth, caching, unlimited requests, developer key provisioning and more.

Apigee is for people for want to provide and use API's - made by people who love APIs.

Try it now for FREE, or find out why EVERYONE is doing it.

Explore the Facebook API and Simplify OAuth 2.0 »

We launched a new tool at Apigee-  the API lifecycle management platform we offer free to the community. We've created a Facebook Graph API Console- a whole new way to interact with, learn and debug the Graph API that lets you easily view requests/responses to the API, share what you are seeing and dig into errors.

The console supports OAuth 2.0 so you can log in using your Facebook credentials- check out the video: 

InsideFacebook has some great coverage by Josh Constine out today on the console and how it works; you can also hop over to the Apigee blog for more details. 

I Heart API Stickers »

Instructions to get your totally, completely, utterly free I <3 API sticker: 

1. Send your name, address and why you love APIs to .(JavaScript must be enabled to view this email address) 

that's it. we promise not to use your address for anything outside of sticker delivery. and if you really don't want to tell us why you <3 APIs, that's ok too. we just want you to have a sticker. 

Zen and the Art of an API Ecosystem: Building Platforms Through Partnership »

This week MySpace launched the Developer Services program to make it easier for developers on their API to use cool tools for creating, deploying and managing their apps. Through the new portal, developers get better and discounted access to frameworks, hosting, monetization and mobile tools and analytics. We're excited to be one of the partners along with services like PushButton Engine, Microsoft BizSpark and PayPal. 

The Developer Services program highlights the new business imperative for API providers- building an ecosystem- and the ways partnerships support that goal.   

From Tech to Platform 

An open API isn't just about making a technology available- it's about building a platform. The new web economy means billions of devices, millions upon millions of users and thousands of APIs. When your API is deeply hooked into the fabric of the internet, the developer world and the ongoing evolution of tools, devices and services, it gains both greater immediate value and longevity.  

Developers are going to use your API with other APIs, they're going to use monetization and analytics tools, and they're more and more likely to use cloud services that make it easy to scale their stuff. There's a growing opportunity for API providers to form partnerships that simultaneously simplify and improve the development process while enriching the API ecosystem. 

This approach to community and ecosystem is both philosophy and business strategy- a belief that empowering developers to access the tools they want is beneficial to all; and a model that supports adoption, innovation and ROI. 

Where in the World is your API? »

One of our favorite new visualizations involves geolocation. Now we provide analytics for where your API requests come from around the world, based on geo-ip lookups. The green dots indicate requests' originating locations, while the sizes of the dots correlate to the number of requests from that location.

A Look at HipChat’s API »

While Twitter and other web 2.0 applications have changed public communications, companies have been clamoring for similar messaging systems for internal use. Used by over 1,000 companies and teams, HipChat is a great solution with deep features to help you supercharge your company's communications. You can create chat rooms for meetings, use it on your mobile phone, have a one-on-one chat with anybody in your company, and securely share files. HipChat recently released their very own API, which is well-designed and documented. Here's a quick demo of what makes HipChat great:

Since Garret Heaton of HipChat uses Apigee, we asked him to answer 5 questions for us:

What do you wish your API would do that it doesn't do today?

Garret:Obviously it'd be nice to have support for all the features users have access to when using HipChat: changing room topics, sending invites, uploading files, creating rooms, etc. It'd also be awesome to have a streaming API (and open up full access via XMPP) so users could build bots and other real-time services.

If you could send one message about building your API back in time to yourself, what would it be?

Garret:Keep it simple! The first versions of our API had a more complex interface for passing auth information, desired response format, and entity IDs. Our initial testers were often confused. It's important for new users to be able to test the API easily using cURL.

What insights into your app or other benefits have you gotten from working with Apigee?

Garret:The 'Response Time' data is really helpful for identifying slower requests. It's really nice not having to build this ourselves. The new debug console is also incredibly helpful when you need to see what your exact request/response data looks like.

What new Apigee feature would you most like to see from Apigee?

Garret:I know you're already working on it, but HTTPS support for mapped domains so our users can use HTTPS [NB: It's coming very soon, we promise!]. Also, a way to create a test console for our API. I think our users would find that very helpful.

How would you like to see developers make use of your API once it is exposed?

Garret:It'd be awesome to have plugins for sending HipChat messages available for lots of other software: Capistrano, Nagios, Subversion, Git, Perforce, Trac, Get Satisfaction, CoTweet, and many other cloud-based tools companies are using these days. We're also looking forward to seeing the creative things people will build that we haven't even thought of yet!

If you're looking for a great collaboration tool to improve your internal communications, be sure to check out HipChat. And keep telling us what Apigee features you'd like to see next so we can provide a better service for you!

Vzaar: A Platform for Merchandising Video »

We all know YouTube is a famous platform for sharing videos. But the advertising that supports YouTube isn't always wanted when you, yourself, are a business who wants to be taken seriously. This is a problem that vzaar solves—hosting professional content and videos for businesses. They provide a professional video platform that allows you to serve high quality videos for your web applications, and many other businesses. Creating videos for your business is a great way to engage with customers and can be an important revenue generating tool. The best part about vzaar is the control they provide, like how your video gets presented and where. They also have a well-documented API that you can use to plug videos right into your application.

Since the CTO of Vzaar, Adrian Sevitz ,uses Apigee, we asked him to share some of his experiences.

 What insights into your app or other benefits have you gotten from working with Apigee?

 Adrian: Both insight into which calls are being accessed, and what the popular API calls are as well as how many hack attempts we get looking for open urls and holes.

 What new Apigee feature would you most like to see from Apigee?

 Adrian: Two things. The first is the ability to limit users by number of calls so we can sell different access limits. The second is to white or blacklist ulrs being access to provide a layer of protection at the api level.

 What mashup, app, or API do you admire?

 Adrian: App wise we love postmark for our emails and spreedly for our billing. Both of them make our life easier. And what could be better than that?

 When your trying to give your business the right impression on a video platform, vzaar is a great way to push your product or service out! Also we want to hear your ideas on www.apigee.com/support so we can provide a better service for all of our users.

Building Apigee for Multiple Clouds:  10 Cloud Portability Lessons Learned »

This is a repost of a piece I prepared this for Shlomo Swidler's panel "Writing Code for Many Clouds" at CloudConnect 2010 and also posted on my own blog earlier this year.   It's a long post, so later I created this short screenr of a cliffs notes version below.

At Sonoa, we have an enterprise product which we turned into a service called Apigee.  From the first, we needed to move beyond just being packaged as a VM and “deployable anywhere” to really living in the cloud.

This is what we’ve learned so far – some of which we anticipated and some of which we reacted to.  Build, deploy, and manage – of the three basic parts of running a service only deploy and manage really change.  The big difference is in operationalization of the system.

Most recently we realized that we needed to be HA across providers and get total control of our latency, so we are building a new datacenter on Rackspace as well.  This is a work in progress so I’ll be reporting from the front lines.

Finally, we’ve helped implement a multi-cloud architecture for ING which has taught us something about where multi-cloud services may be headed.

The first cloud: EC2

1.    Build:

The first and biggest step for any system will be building it as a VM if you haven’t done so before.  Once you have done this, you can practically drop it onto any box.  You’ve become independent of the hardware and other aspects of the operating environment. 

Beyond build, you have to focus on: setting up the network topology, configuring the virtual boxes once they’re up, and managing the result.

2.    Deploy:

 The next phase is figuring out how you bring up instances in your cloud platform.  EC2 has its own interfaces for this, and Rackspace has different ones.  Rightscale normalizes these interfaces and provides a UI.  There’s an open source package with no UI that we evaluated but aren’t using called libcloud. 

Now that you’re hardware independent, you can run as many instances of your service’s components as you can afford.  The main solutions here are Chef and Puppet, both open source.  We use Capistrano for scripting automation. 

Then you need to configure the topology of the different subsystems you’ve built.  Here things get interesting.  EC2 does not support multicasting across your default virtual network; this was tough for us and would be for anyone relying on clustering.  VPN-Cubed from CohesiveFT let us build a private network within our EC2 environment and let us do the multicasting we needed.

Once your network is up and you can push software, it’s just the same as having your own private datacenter.  You can connect from anywhere, manage instances, and get alerts and reports.

3.    Manage:

That brings us to management.  We use Nagios for monitoring our virtual boxes.  We learned that we needed to have a separate machine outside of EC2 as a “monitor monitor” – a Nagios instance that monitored the health and responsiveness of the Nagios box in the cloud environment  We use RightScale for managing all of our accounts and instance creation.  With this setup we’ve had zero downtime since our launch in late August of last year.

We realized at the outset that we wanted to build a service that would be portable, so we chose not to use the least portable features of AWS, such as S3.  While it would have made our life simpler for some of the assets we were managing, there was no corollary (and Walrus, the Eucalyptus storage subsystem that mimics S3, does not count as a corollary, even though it really works).  We did use EBS (Elastic Block Storage) which is so close to a SAN that we felt it was reasonably standard; and forcing our hand was the fact that we needed to solve for persistence and performance. 

But the evils of cloud computing were present as well as the the good.  EC2 does not guarantee the availability of an instance, but the availability of a zone.  As a result we found that the latency of our service had a high degree of jitter (between 5 and 15ms), which was acceptable but not ideal.  The lack of control in this environment means that we’ve been buying instances ahead of our need in order to guarantee not just availability but performance.  This is one of the headaches that cloud computing is supposed to transcend.

In a nutshell – “it’s elastic but you have to manage it.”

So in order to manage the network performance issues (achieve constant performance AND availability) we realized that we needed to go multi-cloud.  We also realized that our core service principle – we’re a cloud service gateway and active proxy for people's API traffic – meant that we had to have a “strongest link” architecture so that no set of failures at a single cloud provider could take down our service.

We’re now building on what we’d anticipated and developing a new instance of our service at Rackspace.  The big changes here are the level of control we have out of the gate for network topology, process isolation, CPU performance… and price, which is higher. 

The second cloud: Rackspace

1.    Build

Architecturally the big differences are database replication and cross-provider load balancing.  This places really specific requirements on your networking design and technology as well as your database design. 

One of the things our service does is store all of our customers’ cloud API traffic for their later use in analytics.  Thinking about data modularly helps with replication.  In a replicated world we need to break out types of datasets – such as customer information and service configuration – into smaller chunks that can meet higher-speed replication requirements cost-effectively, and break them away from all the historical traffic data.  Even the traffic data needs to be handled differently in this world. 

We are now sharding the database into circular tables, where the incoming data is always written to a write-only area, and revolves to the next area every five minutes.  In our user base a 5-minute delay on analytics is more than acceptable (compare this with the SLA for Google Analytics), and the working set of data used for traffic management is handled separately in realtime.  All of this means that we can have either a hot standby or live-live dual-cloud configuration without breaking our customer promise that they can tweak their service at any time at all, and that their analytics are consistently available.  This will also let us evolve both sides of the service as it grows.

2.    Deploy

Deployment tooling stays the same – our old friends RightScale and Capistrano are used to spin and configure instances.

On the networking side, obviously you need to connect your clouds securely in order to replicate between them as well as to exchange performance data which can be used for load balancing.  We found again that VPN-Cubed helps us establish a trusted connection between our heterogeneous cloud environments. 

3.    Manage

Since we are using standard monitoring and management tools – Nagios, RightScale, and Capistrano – these all work in both environments, and our approach of using a “monitor monitor” doesn’t change.. although now we need to monitor monitors in each cloud.

Is there an easier way?

For an infrastructure play like Apigee, we don’t think so.  Given our customer promise of near-zero and predictable latency we need as much control as possible.  For an application-level service play though, we think some parts can be easier.  We’re built on Sonoa technology that manages all of our cloud API traffic processing, as is ING, a financial service company that’s moving to cloud. Their challenge is elasticity in financial modeling – specifically the Monte Carlo simulation workload which is compute-intensive and highly intermittent in use of resource.  When you’re running the simulation, you need all the compute resource you can get.  When you’re not running a simulation, you need almost none.

Cloud infrastructure like EC2 and Rackspace take care of the racking & stacking problem associated with scaling up for Monte Carlo.  You still need to manage that with a  tool like RightScale or libcloud plus your configuration and deployment tool of choice.  But at the higher level where you’re load-balancing between clouds you don’t necessarily need a VPN, as there’s no data replication requirement.  At this layer they’ve implemented a secure API which is called by internal clients, and then this API request is load-balanced by Sonoa’s API gateway.  The gateway then calls the right cloud based on policies set by the monitoring and scheduling software.  So in this situation you are monitoring your cloud instances and letting the API gateway handle the dirty work of dispatching and securing the calls.

10 Lessons Learned From Building to Multiple Clouds:

1.    Get everyone comfortable with virtualization fundamentals, from developers to admins.

2.    Limit your dependency on provider-specific APIs by using 3rd party tools that manage this for you.

3.    There may be SLAs on your cloud instances but there are no SLAs on the APIs your cloud providers give you.

4.    Refuse to use services that have no corollary in other clouds.  It will cost you more in rearchitecture than you gain by using it.

5.    Understand the cost trade-offs for your business of the different clouds’ strengths – especially in the dimension of availability, price, and performance.

6.    Anticipate your needs for data replication and design your databases accordingly.

7.    Pay attention to your networking requirements and network topology.

8.    Consider the granularity of the requests that you need to load balance – is it at the service or API layer or is it finer-grained than that?

9.    You’ll still buy more than you need but the waste ratio is much less in the cloud.

10.    Monitor the monitors!

Apigee API Contest Winner at iPad Developers Camp - Netflix Actors »

The winners of the Apigee sponsored prize at the iPad developers camp was the "Netflix Actors" application. Check out a quick demo of the application below.

How to use Apigee’s Twitter API Test Console. »

Sam Ramji discusses Apigee’s new Twitter API Tools with Robert Scoble. »

Robert Scoble of Rackspace caught up with Sam Ramji to discuss the latest release of Apigee and all the new Twitter centric features. Check out the full interview below!

@sramji demos @apigee @twitterapi features at #chirp »

Sam demoed Apigee's new Twitter API test and debug console at the Twitter Chirp conference yesterday.

There's both a video and the screenr screencast for a clearer view of the screen below. Enjoy!

Apigee’s Evolution »

Launch

Apigee was launched in late August 2009 based on a vision of "APIs Everywhere." We think that this decade will be dominated by APIs in the way that the late 90s were dominated by web pages. We saw how powerful APIs were for building some of the world's most useful services and how they were letting developers and providers innovate faster. We believed that the burning need for the growing API Economy was to enable powerful analytics on APIs - in the same way that Google Analytics powers the web economy. We focused on late-stage API providers who already had APIs in production and needed to measure them ASAP.

We attracted hundreds of users, learned a great deal, and made changes in our interface and architecture. We are indebted to the people who gave our service a try, sent us their thoughts on improving the service, and came back for more. We listened very hard and found we'd attracted not just providers but developers as well, and that it was now our responsibility to serve them well.

Learn

The most striking thing we realized was that as great as APIs are, they're still harder for developers to use than they should be.

Many people write about APIs as if the providers are the supply and developers are the demand, competing for the providers' bandwidth and attention. We think that it's exactly the opposite: developers are the supply, and providers are demanding developers' attention, competing for developers who they are relying on to make their service successful.

We believe that developers power the innovation that everyone is asking for. Making developers' lives easier becomes the shortest path to enabling the API Economy.

Simultaneously we saw that getting the attention of API developers was not easy. You can't go into a tech conference and say "raise your hand if you're an API developer" and expect anything but blank looks. However, specific APIs have very loyal communities. Going into that same conference and asking for "Twitter API developers" will get a very different response.

This brings me to the Twitter API. In a relatively short time this API has grown enormously and attracted tens of thousands of developers who are recognized as collaboratively growing Twitter's presence. It's a rich and well-designed API, and a great one to apply tools to support in testing, debugging, and analysis.

Launch @Chirp

So we've dramatically expanded the Apigee platform. Today we're launching two new tools specifically for developers: the API Console and the API Debugger.

The API Console enables developers to learn the structure of an API, send and received test messages, and share snapshots of those messages with other developers on forums, in email, or anywhere a URL is welcome. For our Chirp release, the API Console supports the Twitter API only, including all of the methods listed at http://api.twitter.com including basic authentication and OAuth (the technology under the "sign in with Twitter" feature on so many sites). We'll continue to expand our support for Twitter over the coming weeks and months.

The API Debugger lets developers drop into calls to any API - including their own - and record all of the requests and responses. These can be filtered out to isolate messages from a specific IP address, those that include a particular header, or all messages that generated errors (400+ return codes). This means no mysteries about whether messages were sent or not, no questions about the parameters or the formatting of the response - it's all displayed on a web page in a readable way. This should greatly reduce the effort required in building and launching API-driven applications.

We've also evolved our previously release tools for API Analysis and API Protection. API Analysis has gained a geolocation report to show where in the world API calls are coming from and a "most popular methods" list for a given API. Appropriate to the Chirp launch, we've also added reports for the number of Tweets and Retweets sent by a given application if it's using the Twitter API. For API Protection we've quintupled the rate limit for our free platform - now supporting up to 50,000 calls per hour per API used by a given application.

Finally, we've learned enough from our users that we are ready to drop the "private preview" from Apigee's service and make it a public beta. If you're interested, sign up and get rolling for free.

Thank you to all our users for their support of Apigee so far, and a special thanks to the Twitter team for their help and inspiration in bringing in the new phase of our service. We think developers deserve "a better way to API" and we are working hard to make our API platform as useful and as fun as possible.

Apigee team members will be at Chirp - both at the conference sessions and Hack Day. You can send a message to @sramji or @earth2marsh if you have feedback or want a hands-on demo. We look forward to seeing you there!

SXSW discussion on API trends and adoption »

Ross Turk shot a great video panel at SXSW on trends in developer and API adoption.

Sam Ramji and Greg Brail from Sonoa, Laura Merling from Alacatel-Lucent, and Martin Tanlow from 3scale talk about what they're seeing in world of APIs, from the latest mobile and social apps to Alcatel-Lucent's Open API strategy for developers building on service provider networks.

Apigee vs. Sonoa ServiceNet for API management »

In a few years, most of your internet traffic might come in not through your website, but instead through mobile devices, tablets and affiliate partners accessing your services through APis.  For two years, we've been helping enterprise customers accelerate their API strategy and deployments with Sonoa ServiceNet.    

Last year we released Apigee as a tool for developers building apps with APIs.   Apigee provides free, self-service website for API analytics and protection. Hundreds of developers are using Apigee to monitor APIs they are consuming (such as the Twitter, Flickr, and Facebook APIs) or APIs that they are providing.   Here are some example apps. 

How do Apigee and Sonoa ServiceNet compare?

It's much like the difference between Google Analytics and Omniture. Apigee (like G analytics) is a free, self-service API analytics and management tool that provides coarse grained analytics and basic throttling policies.  Sonoa ServiceNet is an enterprise-scale API management platform that provides a rich policy framework for customized, complex policies and enterprise-levels of scalability.  While Apigee is available as a free service,  Sonoa ServiceNet is available as both an on-demand an on-premise (both hardeware and software) offerings.  Also, Apigee is itself an app built on the Sonoa ServiceNet platform.

So if you are a developer building an app that uses APIs and want basic API analytics and rate limiting in 5 minutes - give Apigee a spin.  If you are a product or engineering executive thinking about an enterprise API strategy or roadmap, consider these potential requirements and take a look at Sonoa ServiceNet for industrial-strength enterprise API management.

Is Apigee ready for your Production App? »

One frequent question over the last six weeks is "if Apigee is still a preview product can I use it for my production app?"

Yes, you can use Apigee as a proxy for production APIs. Dozens of production apps run on Apigee today. (many of which we'll keep showcasing on this blog)

The current Apigee preview is built on a proven platform and architecture that delivers carrier-grade levels of uptime. Some specifics:

• Apigee's core is our Sonoa ServiceNet enterprise platform. This is the same API Infrastructure that runs over 60 financial services, media, and SaaS companies running critical apps at high traffic levels.
• From the load balancers to the database and everything in between, we built redundancy into every level of Apigee.
• We designed Apigee for zero downtime upgrades so that your proxies will stay up and running even as we apply fixes for bugs and enhance Apigee with new features.
• Our uptime targets for the preview are 99.9% for API proxies and 99% for the Apigee website.
• And we have operational teams in San Francisco, USA and Bangalore, India constantly monitoring Apigee so that we can respond 24x7 to any issues.

So even though Apigee is currently in private preview, we take your business very seriously and we've built the service to be enterprise-grade from the ground up.

Recent Apigee upgrades and fixes »

Earlier this week we released significant UI upgrades for Apigee. We also fixed some bugs identified in our feedback forum.

(We should mention that you won't lose API messages during our planned upgrades - we use a HA architecture so we don't have to schedule downtime.)

The big one is that now the cool screens in the demo video - the animated API setup and proxy rate limiting dialogues (as in this video) - are now live for everyone.  They include some usability tweaks identified by our preview members - thanks.

We also fixed some bugs you found in the API Requests Table and with editing API nicknames.

Here's an overview of the  UI highlights and below are details on more features coming soon.

What's coming next

We're prioritizing our backlog directly based on your feedback.  Coming up soon:

Support for HTTPS & SSL. Thanks to everyone that commented on the solution proposal.

Proxies will come in 2 flavors -  consumer and provider, and we're including Apigee status info in the response header

Finally, we're thrilled when one of our community members suggest a better solution than we had planned.   We love this idea to make IP addresses human friendly.

Thanks again and please keep the ideas coming!

APIs as Dark Matter: our vision for Apigee »

We'd like to share some of our thinking about APIs and why it motivates us to build Apigee into the world's best website for API analytics and management. 

The API Economy 

Web APIs are not mainstream, but they will be. The money being made from Amazon, Facebook and other APIs is just the beginning. Today, APIs are measured in hundreds - about 1,400 listed on ProgrammableWeb. Web UIs, on the other hand, are measured in tens of millions.

In the future, many more websites will provide APIs. And new companies will be formed with revenue models exclusively focused on web APIs. If we look 10 years out it's easy to imagine millions of web APIs.

Because APIs, by their nature, are networked together each additional API will amplify the value of existing APIs. That network effect will create an explosion of value that matches or exceeds the magnitude of today's web economy.

That's the API economy. It's going to be big. But we need some important stuff before it becomes a reality. 

APIs are the dark matter of the web 

We know they're out there. We know they're important. We can infer their existence from mashups and integrations - if we update Twitter on an iPhone it shows up on Facebook. However, we're not directly observing or effecting APIs. And until we do, APIs won't have the massive economic impact that websites have had.

Today, there are hundreds of ways to understand websites, privately (Omniture, Hubspot, Google Analytics, etc.) and publicly (Alexa, Compete, Comscore, etc.). In 1995, when Urchin was founded, that wasn't the case. Back then, there were few ways to understand how websites behaved or what people did with them. As a result, websites were often unreliable, they changed slowly and didn't always have the content people wanted. As the tools for understanding the web evolved, the web itself evolved and became more valuable.

Web APIs are about 10 years behind web UIs. Today, we can't benchmark APIs, we can't see which APIs are popular and we can't effect the way APIs behave without writing a bunch of code. 

APIs at Web Scale 

With Apigee we want to fix these problems. We want to make APIs at web scale a reality.

Our initial set of Apigee features is focused on protection and visibility. API providers can setup policies that enforce their terms of use and ensure uptime, acting as a circuit breaker that protect servers from overloading. Mashup developers can create heartbeat policies that monitor the APIs they rely on. With reports and analytics, API providers and mashup developers will gain visibility into their APIs.

Apigee users will be able to anonymously share their API data. Once API data are public, all of us will benefit from a global understanding of the API web. Just as we use Alexa, for example, to understand the UI web, we envision people using Apigee to understand the API web.

It's important that Apigee be a website and follow the rules of the web: Apigee has a simple pricing matrix with a free version, getting started takes about 2 minutes and Apigee will get better as more people use it.

To make the API economy happen we need tools like Apigee to work at web scale. Our company DNA and the technology Apigee uses - Sonoa ServiceNet's API Router - is all about high-scale networking. We've learned a lot from Sonoa enterprise customers about doing this at carrier grade levels of reliability and scale. 

Our Vision 

Apigee gives API providers and mashup developers the visibility, control and scale they need for their APIs. They will be able to share their data publicly so that all of us benefit from a better understanding of the API web. Once we evolve our tools for understanding APIs, we will see APIs themselves evolve and become more valuable.

We are at the beginning of the web API era. In the future, the value created by the API economy will rival that of today's web economy. 

Try it! 

You can take a look at how Apigee works now with YouTube demo videos: one for API providers and one for API Consumers - developers and mashup artists. You can also request an invitation to try the preview of Apigee today.

Introducing Apigee: Freemium, Self-Service API Management »

   Today we are delighted to announce Apigee. 

Apigee is a website that provides analytics, protection and control for APIs.  If you offer an API you can use Apigee to understand usage, protect your app, and enforce API terms of use.   If you are a developer using APIs in a mashup, mobile or social app, you can use Apigee to get visibility into the actual service levels of the APIs you consume.   

Apigee is freemium and self-service.  You can start using it in minutes and Apigee's Basic service is free for under 10,000 requests per hour.  Apigee is built on the same Sonoa ServiceNet technology that our enterprise customers use for industrial-strength API management.  You can think of it as a freemium, simplified subset of policy framework available in Sonoa technology.

Beginning today we are offering Apigee in a private, invitation-only preview.  Anybody can sign up for an invitation here.   More details are on the Apigee blog.