Imagine, if you will, you have a popular [app] hosted on a cloud computing service which is also used by a number of other [app]s. If this service forces clients to share IPs (and they all do, in practice) its more or less inevitable that you'll fall afoul of our request quota system, which is IP based.

This was a theoretical problem until recently, when StackPrinter* (on Google App Engine) reported encountering this.

The Solution

In a nutshell, [app]s we authorize will be given a secret key which can be exchange (at StackAuth, via the /auth route) for a temporary authorization token. When that authorization token is passed on an API query (via the auth parameter) the request will be counted against a non-IP based quota.

/auth is the first POST method in the API, to use it one merely POSTs their secret key to /auth?key=<existing app key>. The response is a trivial JSON object containing either the temporary authorization token, or an error message.

What this means for your [app]

For 99% of all [app]s, nothing. This only really changes anything for server side [app]s, on cloud computing services, and even then only those with significant traffic.

If you're considering developing an [app] using something akin to Google App Engine, strongly consider alternatives. The handicap of a shared IP can be a significant one.

Does my [app] qualify?

Qualifying [app]s should

  1. Run solely on a server
    • The secret key must be kept, well, secret. You can't do this if you ship code to a user.
  2. Have actually encountered quota problems
  3. Have a significant user base
  4. Not be evil
    • Restricting how the API is used is a fool's errand, but we won't raise limits for any [app] we consider bad for the sites or community.

These are guidelines, not hard and fast rules, and each [app] will be considered on a case-by-case basis. If you think your [app] should be authorized, use the "Contact Us" link at the bottom of every page to send us a request.

About Security

This scheme will never be extended to client side [app]s. Nor will it live as long as the v1.0 API, at least we don't guarantee it will. There are a lot of little security issues with it, plus the elephant in the room of actually passing a "secret" token around.

The one real hardening bit (and one of the many things that makes it unsuitable for client side [app]s) is that an [app] can only have a single authorization token active at any one time. Subsequent calls to /auth with the same secret key invalidate the previously issued authorization tokens. Accordingly, any [app] that wants to use this scheme must be capable of some internal key use synchronization.

It is very likely that this entire scheme will be deprecated shortly after a more proper authentication scheme is introduced in later API version, it is intended as a stop-gap solution.

*Many thanks to systempuntoout for beta testing this scheme for us.

  • 1
    +1 One thing related to this faq: using Token authentication does not prevent your [app] to be throttled by the request throttling policy; ie, your authenticated [app] could be throttled while fetching an url if other app[s] on your same IP have already consumed the 30 requests per 5 seconds plafond. Commented Oct 27, 2010 at 13:25
  • "plafond" == "ceiling" Commented Oct 27, 2010 at 20:46
  • @systempuntoout: No, just providing information for those who come along who, like me, didn't know that and don't speak French or know architecture. Thanks for adding a new word to my vocabulary. Commented Oct 27, 2010 at 23:23
  • 1
    I'm super-glad to see this was added :) Thank you so much for listening to the pleas of the users! Commented Jan 10, 2011 at 1:28
  • @Kevin this is not supported in the new V2.0 Api right? What should we do to authenticate an entirely app (and not a user) to get an access_token and its 10k separate app quota? Commented Apr 24, 2012 at 13:52
  • 1
    @systempuntoout - you should use one of your (as in, your user's) app "slots". Basically, as the app author authenticate a no_expiry token and use it. Commented Apr 24, 2012 at 16:53


You must log in to answer this question.

Browse other questions tagged .