Stack Exchange API v2.3
This is the documentation for the v2.3 Stack Exchange API (with both authentication and write support). If you have additional questions, or believe you have encountered a bug, don't hesitate to post a question on Stack Apps.
If your application is in a runnable state (even a beta one), Stack Apps is also the place to list it.
General
Applications should be registered on Stack Apps to get a request key. Request keys grant more requests per day, and are necessary for using access_tokens created via authentication.
All API responses are JSON, we do support JSONP with the callback query parameter.
Every response in the API is returned in a common "wrapper" object, for easier and more consistent parsing.
Additionally, all API responses are compressed. The Content-Encoding header is always set, but some proxies will strip this out. The proper way to decode API responses can be found here.
API usage is subject to a number of throttles. In general, applications should strive to make as few requests as possible to satisfy their function.
API responses are heavily cached. Polling for changes should be done sparingly in any case, and polling at a rate faster than once a minute (for semantically identical requests) is considered abusive.
Developers can trim API responses down to just the fields they are interested in using custom filters. Many types have fields that are not normally returned (question bodies, for example) that can likewise be requested via a custom filter.
There are a few methods which require that the application be acting on behalf of a user in order to be invoked. For authentication purposes, the Stack Exchange API implements OAuth 2.0 (templated on Facebook's implementation in pursuit of developer familiarity).
A number of methods in the Stack Exchange accept dates as parameters and return dates as properties, the format of these dates is consistent and documented. The cliff-notes version is, all dates in the Stack Exchange API are in unix epoch time.
Unless otherwise noted, the maximum size of any page is 100, any {ids} parameter likewise is capped at 100 elements, all indexes
start at 1.
The maximum page number that will be returned for anonymous API access (no access token or app key) is 25
If a parameter name is plural it accepts vectorized requests, otherwise a single value may be passed. Compare users/{id}/inbox and /users/{ids}.
It is possible to compose reasonably complex queries against the live Stack Exchange sites using the min, max,
fromdate, todate, and sort parameters. Most, but not all, methods accept some or all of these parameters,
the documentation for individual methods will highlight which do. Most methods also have a common set of paging parameters.
Some methods require access_tokens with particular scopes, such as private_info (/users/{id}/reputation-history/full for example) or write_access (/questions/add). Certain fields require access_tokens with the private_info scope, such as answer.upvoted; the documentation for each time makes note of these fields.
Per-Site Methods
Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"),
or a short form identified by api_site_parameter on the site object.
Answers
Badges
Collectives
Comments
Events
Info
Posts
Privileges
Questions
Revisions
Search
Suggested Edits
Tags
Users
All user methods that take an {ids} parameter have a /me equivalent method that takes an access_token instead.
These methods are provided for developer convenience, with the exception of plain /me, which is actually necessary for discovering
which user authenticated to an application.
Network Methods
These methods return data across the entire Stack Exchange network of sites. Accordingly, you do not pass a site parameter to them.
Access Tokens
access_tokens when it is done with them.
access_tokens it has, useful for debugging.