12 Ways to Limit an API

John Musser, April 2nd, 2007

The vast majority of the over 400 open APIs listed here have imposed some limitations on how much they can be used, certainly in the free use model. There are good reasons for this ranging from preventing abuse, controlling costs, or other business-driven reasons. Just over a year ago, in 7 ways to limit API use we looked at some of these. With twice as many APIs now listed it’s a good time to check back and see what other ways APIs get throttled. As a refresher, here’s the original list:

  • Time based limits: 1 call per second, Last.fm
  • Call Volume by Address: 5,000 queries per IP per day, Yahoo! Image Search
  • Call volume per-application: 10,000 queries per application per day MSN Search
  • Return results volume: 10 results per query, the now deprecated Google Search, or 100 items returned per call, Tailrank, or 100 blogs per map FeedMap
  • Data Transmission Volume: 120 packets of 1.6KB per minute, MSN Messenger
  • Formula: Monthly quotas based on various factors, Google AdWords
  • Kindness of strangers: “Please be gentle with Simpy’s server”, Simpy

There are over 40 variations of the above list, mostly differing in exact size of the limit. What happens if you hit one of these limits? It depends. Most return an error code and/or message, some unfortunately leave it undefined.

And here are a few more to keep in mind, some are more exact than others…

  • Per second and per month limits: Up to 1 call per second for up to 60,000 requests per month, Amazon Historical Pricing
  • Login limits: 250,000 logins per day or 2 million per month, AOL Instant Messenger, AIM
  • Varies within a range: determined by overall system load, GeoCoder.ca
  • As needed: “The servers will block excessive requests”, ISBNdb
  • Heads-up: not so much a limit as a request, “Let me know if you’re going to hit it hard”, Where’s Tim API

Tags: Issues, Money
Both comments and pings are currently closed.

9 Responses to “12 Ways to Limit an API”

April 2nd, 2007
at 8:50 am
Comment by: Oren Michels

Thanks for helping Mashery with our product roadmap, John!

Mashery’s clients can currently throttle the APIs we manange for them according to most of these techniques, and the rest are on our development roadmap for release in the near future.

Most of these presuppose the issuance of a developer key, which is passed with the API request to identify their calls. What goes hand-in-hand with the throttling techniques are the means of authentication that some APIs apply to API requests to gain access in the first place. These range from limiting requests to certain IP addresses, geographies, user agents or referring domains, to requiring username/password authentication to be passed, to implementing standards-based authentication such as X509. We’re already seeing requests for some of these, and expect that as more sensitive or strategically important data and services are made available through APIs, stronger authentication will become more commonplace.

April 2nd, 2007
at 12:02 pm
Comment by: John Musser

Glad I can help :-) And you make a very good point that as more higher-value services come on line there will be an even greater need for new ways to throttle usage.

April 2nd, 2007
at 3:19 pm
Comment by: rascunho » Blog Archive » links for 2007-04-02

[...] 12 ways… (tags: blog.programmableweb.com 2007 at_tecp mashup webservices blog_post) [...]

April 6th, 2007
at 6:57 am
Comment by: All in a days work…

[...] 12 Ways to Limit an API (tags: API) [...]

April 6th, 2007
at 8:09 am
Comment by: alexbarnett.net blog : 7 Thoughts on the Business of API Throttling

[...] John Musser over at ProgrammableWeb.com has summarized the various ways (he's outlined 12) API providers can control access to their web services. As John says,  "There are good reasons for this ranging from preventing abuse, controlling costs, or other business-driven reasons."John triggered a few things in my mind with this post…Thinking out loud now…7 Partially Random Thoughts on the Business of API ThrottlingWeb APIs will be a key driver of future of the networked, services-based economiesThe science of web API throttling is set to become a core business competency – not just a technical competency - for (hundreds of) thousands of businessesBusinesses need to learn about the business of API-based business models (an area where there is some experimentation and learning is going on today, but not enough)Business expertise in designing and evolving API-based business models will be a highly valued skill / commodityStandardized business models need to (and will) emerge regarding web APIs, similar to how there are standardized business contracts todayTechnical competency pertaining to API throttling will become exponentially more complex to execute and operateA significant number of small and medium-sized business (the long tail of today's economies) that want to thrive in the networked economy will need to make a decision in the near future: "do we spend large amounts of resources in the technical operation of API service delivery and throttling expertise in-house, or should we outsource this?" Posted: Friday, April 06, 2007 6:21 AM by alexbarnett Filed under: Web 2.0, webservices, APIs, SOA, enterprise2.0, SaaS, BungeeLabs [...]

April 14th, 2007
at 12:05 pm
Comment by: carlo beccaria - blog / I meccanismi di throttling delle API

[...] Quali sono i meccanismi piu’ frequentemente usati per limitare l’ accesso alle API ? [...]

June 8th, 2009
at 1:28 am
Comment by: Microsoft Releases Bing API - With No Usage Quotas

[...] a world where APIs are often limited in many ways, it’s notable that in addition to these technical updates that Microsoft has removed the API [...]

September 21st, 2010
at 8:53 pm
Comment by: Internet Alchemy » links for 2008-11-13

[...] 12 Ways to Limit an API (tags: webservices web2.0) [...]

May 8th, 2012
at 11:28 am
Comment by: links for 2008-11-13 « Internet Alchemy

[...] 12 Ways to Limit an API (tags: webservices web2.0) Share this:TwitterRedditFacebookDiggLike this:LikeBe the first to like this post. [...]

Follow the PW team on Twitter

ProgrammableWeb
APIs, mashups and code. Because the world's your programmable oyster.

John Musser
Founder, ProgrammableWeb

Adam DuVander
Executive Editor, ProgrammableWeb. Author, Map Scripting 101. Lover, APIs.