openapi.city
Sign in

Stack Exchange

Q&A community platform API

api.stackexchange.com ↗
Version
2.0
OpenAPI
3.0.0
Endpoints
124
Schemas
34
85
Quality
Updated
3 days ago
Developer tools q-a community developer-tools
Use this API in your AI agent

Query structured spec data via REST or MCP. Get exactly what your agent needs.

Get API Key

Server URLs

https://api.stackexchange.com/2.0

Endpoints

GET POST PUT PATCH DELETE

Accesstoken 3 endpoints

GET /access-tokens/{accessTokens}

Reads the properties for a set of access tokens.

{accessTokens} can contain up to 20 access tokens. These are obtained by authenticating a user using OAuth 2.0.

This method returns a list of access_tokens.

operationId: AccessToken_listPropertiesForMultipleTokens

Parameters

Name In Required Type Description
accessTokens path required string

String list (semicolon delimited).
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /access-tokens/{accessTokens}
GET /access-tokens/{accessTokens}/invalidate

Immediately expires the access tokens passed. This method is meant to allow an application to discard any active access tokens it no longer needs.

{accessTokens} can contain up to 20 access tokens. These are obtained by authenticating a user using OAuth 2.0.

This method returns a list of access_tokens.

operationId: AccessToken_invalidateList

Parameters

Name In Required Type Description
accessTokens path required string

String list (semicolon delimited).
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /access-tokens/{accessTokens}/invalidate
GET /apps/{accessTokens}/de-authenticate

Passing valid access_tokens to this method causes the application that created them to be de-authorized by the user associated with each access_token. This will remove the application from their apps tab, and cause all other existing access_tokens to be destroyed.

This method is meant for uninstalling applications, recovering from access_token leaks, or simply as a stronger form of /access-tokens/{accessTokens}/invalidate.

Nothing prevents a user from re-authenticate to an application that has de-authenticated itself, the user will be prompted to approve the application again however.

{accessTokens} can contain up to 20 access tokens. These are obtained by authenticating a user using OAuth 2.0.

This method returns a list of access_tokens.

operationId: AccessToken_deauthenticateList

Parameters

Name In Required Type Description
accessTokens path required string

String list (semicolon delimited).
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /apps/{accessTokens}/de-authenticate

Answer 12 endpoints

GET /answers

Returns all the undeleted answers in the system.

The sorts accepted by this method operate on the follow fields of the answer object:

  • activity - last_activity_date
  • creation - creation_date
  • votes - score
    activity is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

This method returns a list of answers.

operationId: Answer_getList

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = activity => date
sort = creation => date
sort = votes => number
min query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /answers
GET /answers/{ids}

Gets the set of answers identified by ids.

This is meant for batch fetcing of questions. A useful trick to poll for updates is to sort by activity, with a minimum date of the last time you polled.

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for answer_id on answer objects.

The sorts accepted by this method operate on the follow fields of the answer object:

  • activity - last_activity_date
  • creation - creation_date
  • votes - score
    activity is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

This method returns a list of answers.

operationId: Answer_getListByIds

Parameters

Name In Required Type Description
ids path required string

Number list (semicolon delimited).
order query optional string —
max query optional string

sort = activity => date
sort = creation => date
sort = votes => number
min query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /answers/{ids}
GET /answers/{ids}/comments

Gets the comments on a set of answers.

If you know that you have an answer id and need the comments, use this method. If you know you have a question id, use /questions/{id}/comments. If you are unsure, use /posts/{id}/comments.

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for answer_id on answer objects.

The sorts accepted by this method operate on the follow fields of the comment object:

  • creation - creation_date
  • votes - score
    creation is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

This method returns a list of comments.

operationId: Answer_getCommentsByIds

Parameters

Name In Required Type Description
ids path required string

Number list (semicolon delimited).
order query optional string —
max query optional string

sort = creation => date
sort = votes => number
min query optional string

sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /answers/{ids}/comments
GET /me/answers

Returns the answers owned by the user associated with the given access_token.

This method returns a list of answers.

operationId: Answer_getUserAnswersList

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = activity => date
sort = creation => date
sort = votes => number
min query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/answers
GET /me/questions/no-answers

Returns the questions owned by the user associated with the given access_token that have no answers.

This method returns a list of questions.

operationId: Answer_listNoAnswerQuestions

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = activity => date
sort = creation => date
sort = votes => number
min query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/questions/no-answers
GET /me/questions/unanswered

Returns the questions owned by the user associated with the given access_token that are not considered answered.

This method returns a list of questions.

operationId: Answer_userUnansweredQuestionsGet

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = activity => date
sort = creation => date
sort = votes => number
min query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/questions/unanswered
GET /me/tags/{tags}/top-answers

Returns the top 30 answers the user associated with the given access_token has posted in response to questions with the given tags.

This method returns a list of answers.

operationId: Answer_getUserTopAnswers

Parameters

Name In Required Type Description
tags path required string

String list (semicolon delimited).
order query optional string —
max query optional string

sort = activity => date
sort = creation => date
sort = votes => number
min query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/tags/{tags}/top-answers
GET /me/top-answer-tags

Returns the user identified by access_token’s top 30 tags by answer score.

This method returns a list of top tag objects.

operationId: Answer_getUserTopTags

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/top-answer-tags
GET /questions/no-answers

Returns questions which have received no answers.

Compare with /questions/unanswered which mearly returns questions that the sites consider insufficiently well answered.

This method corresponds roughly with the this site tab.

To constrain questions returned to those with a set of tags, use the tagged parameter with a semi-colon delimited list of tags. This is an and contraint, passing tagged=c;java will return only those questions with both tags. As such, passing more than 5 tags will always return zero results.

The sorts accepted by this method operate on the follow fields of the question object:

  • activity - last_activity_date
  • creation - creation_date
  • votes - score
    activity is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

This method returns a list of questions.

operationId: Answer_listNoAnswerQuestions

Parameters

Name In Required Type Description
tagged query optional string

String list (semicolon delimited).
order query optional string —
max query optional string

sort = activity => date
sort = creation => date
sort = votes => number
min query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /questions/no-answers
GET /questions/unanswered

Returns questions the site considers to be unanswered.

Note that just because a question has an answer, that does not mean it is considered answered. While the rules are subject to change, at this time a question must have at least one upvoted answer to be considered answered.

To constrain questions returned to those with a set of tags, use the tagged parameter with a semi-colon delimited list of tags. This is an and contraint, passing tagged=c;java will return only those questions with both tags. As such, passing more than 5 tags will always return zero results.

Compare with /questions/no-answers.

This method corresponds roughly with the unanswered tab.

The sorts accepted by this method operate on the follow fields of the question object:

  • activity - last_activity_date
  • creation - creation_date
  • votes - score
    activity is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

This method returns a list of questions.

operationId: Answer_getListOfUnansweredQuestions

Parameters

Name In Required Type Description
tagged query optional string

String list (semicolon delimited).
order query optional string —
max query optional string

sort = activity => date
sort = creation => date
sort = votes => number
min query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /questions/unanswered
GET /questions/{ids}/answers

Gets the answers to a set of questions identified in id.

This method is most useful if you have a set of interesting questions, and you wish to obtain all of their answers at once or if you are polling for new or updates answers (in conjunction with sort=activity).

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for question_id on question objects.

The sorts accepted by this method operate on the follow fields of the answer object:

  • activity - last_activity_date
  • creation - creation_date
  • votes - score
    activity is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

This method returns a list of answers.

operationId: Answer_getListByQuestionIds

Parameters

Name In Required Type Description
ids path required string

Number list (semicolon delimited).
order query optional string —
max query optional string

sort = activity => date
sort = creation => date
sort = votes => number
min query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /questions/{ids}/answers
GET /tags/{tag}/top-answerers/{period}

Returns the top 30 answerers active in a single tag, of either all-time or the last 30 days.

This is a view onto the data presented on the tag info page on the sites.

This method returns a list of tag score objects.

operationId: Answer_tagTopAnswerers

Parameters

Name In Required Type Description
tag path required string —
period path required string —
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags/{tag}/top-answerers/{period}

Associated 1 endpoints

GET /me/associated

Returns all of a user’s associated accounts, given an access_token for them.

This method returns a list of network users.

operationId: Associated_getUserAccounts

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/associated

Badge 7 endpoints

GET /badges

Returns all the badges in the system.

Badge sorts are a tad complicated. For the purposes of sorting (and min/max) tag_based is considered to be greater than named.

This means that you can get a list of all tag based badges by passing min=tag_based, and conversely all the named badges by passing max=named, with sort=type.

For ranks, bronze is greater than silver which is greater than gold. Along with sort=rank, set max=gold for just gold badges, max=silver&min=silver for just silver, and min=bronze for just bronze.

rank is the default sort.

This method returns a list of badges.

operationId: Badge_listBadges

Parameters

Name In Required Type Description
inname query optional string —
order query optional string —
max query optional string

sort = rank => string
sort = name => string
sort = type => string
min query optional string

sort = rank => string
sort = name => string
sort = type => string
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /badges
GET /badges/name

Gets all explicitly named badges in the system.

A named badged stands in opposition to a tag-based badge. These are referred to as general badges on the sites themselves.

For the rank sort, bronze is greater than silver which is greater than gold. Along with sort=rank, set max=gold for just gold badges, max=silver&min=silver for just silver, and min=bronze for just bronze.

rank is the default sort.

This method returns a list of badges.

operationId: Badge_getAllNamedBadges

Parameters

Name In Required Type Description
inname query optional string —
order query optional string —
max query optional string

sort = rank => string
sort = name => string
min query optional string

sort = rank => string
sort = name => string
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /badges/name
GET /badges/recipients

Returns recently awarded badges in the system.

As these badges have been awarded, they will have the badge.user property set.

This method returns a list of badges.

operationId: Badge_getRecentAwardedBadges

Parameters

Name In Required Type Description
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /badges/recipients
GET /badges/tags

Returns the badges that are awarded for participation in specific tags.

For the rank sort, bronze is greater than silver which is greater than gold. Along with sort=rank, set max=gold for just gold badges, max=silver&min=silver for just silver, and min=bronze for just bronze.

rank is the default sort.

This method returns a list of badges.

operationId: Badge_listTagsBadges

Parameters

Name In Required Type Description
inname query optional string —
order query optional string —
max query optional string

sort = rank => string
sort = name => string
min query optional string

sort = rank => string
sort = name => string
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /badges/tags
GET /badges/{ids}

Gets the badges identified in id.

Note that badge ids are not constant across sites, and thus should be looked up via the /badges method. A badge id on a single site is, however, guaranteed to be stable.

Badge sorts are a tad complicated. For the purposes of sorting (and min/max) tag_based is considered to be greater than named.

This means that you can get a list of all tag based badges by passing min=tag_based, and conversely all the named badges by passing max=named, with sort=type.

For ranks, bronze is greater than silver which is greater than gold. Along with sort=rank, set max=gold for just gold badges, max=silver&min=silver for just silver, and min=bronze for just bronze.

rank is the default sort.

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for badge_id on badge objects.

This method returns a list of badges.

operationId: Badge_getBadgesByIds

Parameters

Name In Required Type Description
ids path required string

Number list (semicolon delimited).
order query optional string —
max query optional string

sort = rank => string
sort = name => string
sort = type => string
min query optional string

sort = rank => string
sort = name => string
sort = type => string
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /badges/{ids}
GET /badges/{ids}/recipients

Returns recently awarded badges in the system, constrained to a certain set of badges.

As these badges have been awarded, they will have the badge.user property set.

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for badge_id on badge objects.

This method returns a list of badges.

operationId: Badge_getRecentAwardedRecipients

Parameters

Name In Required Type Description
ids path required string

Number list (semicolon delimited).
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /badges/{ids}/recipients
GET /me/badges

Returns the badges earned by the user associated with the given access_token.

This method returns a list of badges.

operationId: Badge_getUserBadges

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = rank => string
sort = name => string
sort = type => string
min query optional string

sort = rank => string
sort = name => string
sort = type => string
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/badges

Comment 7 endpoints

GET /comments

Gets all the comments on the site.

If you’re filtering for interesting comments (by score, creation date, etc.) make use of the sort paramter with appropriate min and max values.

If you’re looking to query conversations between users, instead use the /users/{ids}/mentioned and /users/{ids}/comments/{toid} methods.

The sorts accepted by this method operate on the follow fields of the comment object:

  • creation - creation_date
  • votes - score
    creation is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

This method returns a list of comments.

operationId: Comment_listComments

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = creation => date
sort = votes => number
min query optional string

sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /comments
GET /comments/{ids}

Gets the comments identified in id.

This method is most useful if you have a cache of comment ids obtained through other means (such as /questions/{id}/comments) but suspect the data may be stale.

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for comment_id on comment objects.

The sorts accepted by this method operate on the follow fields of the comment object:

  • creation - creation_date
  • votes - score
    creation is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

This method returns a list of comments.

operationId: Comment_getCommentsByIds

Parameters

Name In Required Type Description
ids path required string

Number list (semicolon delimited).
order query optional string —
max query optional string

sort = creation => date
sort = votes => number
min query optional string

sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /comments/{ids}
POST /comments/{id}/delete

Deletes a comment.

Use an access_token with write_access to delete a comment.

In practice, this method will never return an object.

operationId: Comment_deleteAction

Parameters

Name In Required Type Description
id path required integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.
preview query optional boolean —

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
POST /comments/{id}/delete
POST /comments/{id}/edit

Edit an existing comment.

Use an access_token with write_access to edit an existing comment.

This method return the created comment.

operationId: Comment_editExisting

Parameters

Name In Required Type Description
id path required integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.
body query optional string —
preview query optional boolean —

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
POST /comments/{id}/edit
GET /me/comments

Returns the comments owned by the user associated with the given access_token.

This method returns a list of comments.

operationId: Comment_listOwnedComments

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = creation => date
sort = votes => number
min query optional string

sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/comments
GET /me/comments/{toId}

Returns the comments owned by the user associated with the given access_token that are in reply to the user identified by {toId}.

This method returns a list of comments.

operationId: Comment_getReplyList

Parameters

Name In Required Type Description
toId path required integer —
order query optional string —
max query optional string

sort = creation => date
sort = votes => number
min query optional string

sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/comments/{toId}
GET /questions/{ids}/comments

Gets the comments on a question.

If you know that you have an question id and need the comments, use this method. If you know you have a answer id, use /answers/{ids}/comments. If you are unsure, use /posts/{ids}/comments.

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for question_id on question objects.

The sorts accepted by this method operate on the follow fields of the comment object:

  • creation - creation_date
  • votes - score
    creation is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

This method returns a list of comments.

operationId: Comment_getCommentsList

Parameters

Name In Required Type Description
ids path required string

Number list (semicolon delimited).
order query optional string —
max query optional string

sort = creation => date
sort = votes => number
min query optional string

sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /questions/{ids}/comments

Edit 3 endpoints

GET /me/suggested-edits

Returns the suggested edits the user identified by access_token has submitted.

This method returns a list of suggested-edits.

operationId: Edit_getUserSuggestedEdits

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = creation => date
sort = approval => date
sort = rejection => date
min query optional string

sort = creation => date
sort = approval => date
sort = rejection => date
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/suggested-edits
GET /suggested-edits

Returns all the suggested edits in the systems.

This method returns a list of suggested-edits.

The sorts accepted by this method operate on the follow fields of the suggested_edit object:

  • creation - creation_date
  • approval - approval_date Does not return unapproved suggested_edits
  • rejection - rejection_date Does not return unrejected suggested_edits
    creation is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

operationId: Edit_listSuggestedEdits

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = creation => date
sort = approval => date
sort = rejection => date
min query optional string

sort = creation => date
sort = approval => date
sort = rejection => date
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /suggested-edits
GET /suggested-edits/{ids}

Returns suggested edits identified in ids.

{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for suggested_edit_id on suggested_edit objects.

The sorts accepted by this method operate on the follow fields of the suggested_edit object:

  • creation - creation_date
  • approval - approval_date Does not return unapproved suggested_edits
  • rejection - rejection_date Does not return unrejected suggested_edits
    creation is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

This method returns a list of suggested-edits.

operationId: Edit_listSuggestedEdits

Parameters

Name In Required Type Description
ids path required string

Number list (semicolon delimited).
order query optional string —
max query optional string

sort = creation => date
sort = approval => date
sort = rejection => date
min query optional string

sort = creation => date
sort = approval => date
sort = rejection => date
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /suggested-edits/{ids}

Error 2 endpoints

GET /errors

Returns the various error codes that can be produced by the API.

This method is provided for discovery, documentation, and testing purposes, it is not expected many applications will consume it during normal operation.

For testing purposes, look into the /errors/{id} method which simulates errors given a code.

This method returns a list of errors.

operationId: Error_listErrors

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /errors
GET /errors/{id}

This method allows you to generate an error.

This method is only intended for use when testing an application or library. Unlike other methods in the API, its contract is not frozen, and new error codes may be added at any time.

This method results in an error, which will be expressed with a 400 HTTP status code and setting the error* properties on the wrapper object.

operationId: Error_generateError

Parameters

Name In Required Type Description
id path required integer —

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /errors/{id}

Event 1 endpoints

GET /events

Returns a stream of events that have occurred on the site.

The API considers the following “events”:

  • posting a question
  • posting an answer
  • posting a comment
  • editing a post
  • creating a user

Events are only accessible for 15 minutes after they occurred, and by default only events in the last 5 minutes are returned. You can specify the age of the oldest event returned by setting the since parameter.

It is advised that developers batch events by ids and make as few subsequent requests to other methods as possible.

This method returns a list of events.

operationId: Event_listEvents

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.
since query optional integer

Unix date.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /events

Favorite 1 endpoints

GET /me/favorites

Returns the questions favorites by the user associated with the given access_token.

This method returns a list of questions.

operationId: Favorite_getUserFavorites

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort = added => date
min query optional string

sort = activity => date
sort = creation => date
sort = votes => number
sort = added => date
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/favorites

Filter 2 endpoints

GET /filters/create

Creates a new filter given a list of includes, excludes, a base filter, and whether or not this filter should be “unsafe”.

Filter “safety” is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

If no base filter is specified, the default filter is assumed. When building a filter from scratch, the none built-in filter is useful.

When the size of the parameters being sent to this method grows to large, problems can occur. This method will accept POST requests to mitigate this.

It is not expected that many applications will call this method at runtime, filters should be pre-calculated and “baked in” in the common cases. Furthermore, there are a number of built-in filters which cover common use cases.

This method returns a single filter.

operationId: Filter_createFilter

Parameters

Name In Required Type Description
base query optional string —
exclude query optional string

String list (semicolon delimited).
include query optional string

String list (semicolon delimited).
unsafe query optional boolean —

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /filters/create
GET /filters/{filters}

Returns the fields included by the given filters, and the “safeness” of those filters.

It is not expected that this method will be consumed by many applications at runtime, it is provided to aid in debugging.

{filters} can contain up to 20 semicolon delimited filters. Filters are obtained via calls to /filters/create, or by using a built-in filter.

This method returns a list of filters.

operationId: Filter_getFilterDetailsByIds

Parameters

Name In Required Type Description
filters path required string

String list (semicolon delimited).

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /filters/{filters}

Information 2 endpoints

GET /info

Returns a collection of statistics about the site.

Data to facilitate per-site customization, discover related sites, and aggregate statistics is all returned by this method.

This data is cached very aggressively, by design. Query sparingly, ideally no more than once an hour.

This method returns an info object.

operationId: Information_getStatistics

Parameters

Name In Required Type Description
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /info
GET /tags

Returns the tags found on a site.

The inname parameter lets a consumer filter down to tags that contain a certain substring. For example, inname=own would return both “download” and “owner” amongst others.

This method returns a list of tags.

The sorts accepted by this method operate on the follow fields of the tag object:

  • popular - count
  • activity - the creation_date of the last question asked with the tag
  • name - name
    popular is the default sort.

It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.

operationId: Information_getTagsList

Parameters

Name In Required Type Description
inname query optional string —
order query optional string —
max query optional string

sort = popular => number
sort = activity => date
sort = name => string
min query optional string

sort = popular => number
sort = activity => date
sort = name => string
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags

Mention 1 endpoints

GET /me/mentioned

Returns the comments mentioning the user associated with the given access_token.

This method returns a list of comments.

operationId: Mention_userCommentsList

Parameters

Name In Required Type Description
order query optional string —
max query optional string

sort = creation => date
sort = votes => number
min query optional string

sort = creation => date
sort = votes => number
sort query optional string —
fromdate query optional integer

Unix date.
todate query optional integer

Unix date.
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/mentioned

Merge 1 endpoints

GET /me/merges

Returns a record of merges that have occurred involving a user identified by an access_token.

This method allows you to take now invalid account ids and find what account they’ve become, or take currently valid account ids and find which ids were equivalent in the past.

This is most useful when confirming that an account_id is in fact “new” to an application.

Account merges can happen for a wide range of reasons, applications should not make assumptions that merges have particular causes.

Note that accounts are managed at a network level, users on a site may be merged due to an account level merge but there is no guarantee that a merge has an effect on any particular site.

This method returns a list of account_merge.

operationId: Merge_getAccountMergeList

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/merges

Message 3 endpoints

GET /inbox

Returns a user’s inbox.

This method requires an access_token, with a scope containing “read_inbox”.

This method returns a list of inbox items.

operationId: Message_listInboxItems

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /inbox
GET /inbox/unread

Returns the unread items in a user’s inbox.

This method requires an access_token, with a scope containing “read_inbox”.

This method returns a list of inbox items.

operationId: Message_getUnreadItems

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
since query optional integer

Unix date.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /inbox/unread
GET /me/inbox

Returns the user identified by access_token’s inbox.

This method requires an access_token, with a scope containing “read_inbox”.

This method returns a list of inbox items.

operationId: Message_getInboxItems

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/inbox

Notification 4 endpoints

GET /me/inbox/unread

Returns the unread items in the user identified by access_token’s inbox.

This method requires an access_token, with a scope containing “read_inbox”.

This method returns a list of inbox items.

operationId: Notification_getUnreadItemsInInbox

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.
since query optional integer

Unix date.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/inbox/unread
GET /me/notifications

Returns a user’s notifications, given an access_token.

This method requires an access_token, with a scope containing “read_inbox”.

This method returns a list of notifications.

operationId: Notification_getUserNotificationsList

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/notifications
GET /me/notifications/unread

Returns a user’s unread notifications, given an access_token.

This method requires an access_token, with a scope containing “read_inbox”.

This method returns a list of notifications.

operationId: Notification_getUnreadItemsInInbox

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.
site query required string

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.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/notifications/unread
GET /notifications

Returns a user’s notifications.

This method requires an access_token, with a scope containing “read_inbox”.

This method returns a list of notifications.

operationId: Notification_getUserNotifications

Parameters

Name In Required Type Description
pagesize query optional integer —
page query optional integer —
filter query optional string

#Discussion

The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user’s badge counts it could exclude user.badge_counts whenever it calls a method that returns users.

An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.

Filters are immutable and non-expiring. An application can safely “bake in” any filters that are created, it is not necessary (or advisable) to create filters at runtime.

The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).

#Safety

Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.

Note that this does not mean that “safe” filter is mearly an “unsafe” one with all fields passed though UrlEncode(…). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).

When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the “safe” data is the only accessible data it will be returned even in “unsafe” filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.

#Built In Filters

The following filters are built in:

default, each type documents which fields are returned under the default filter (for example, answers).
withbody, which is default plus the *.body fields
none, which is empty
total, which includes just .total

#Compatibility with V1.x

For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.
callback query optional string

All API responses are JSON, we do support JSONP with the callback query parameter.

Responses

200

OK
400

bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
401

access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
402

invalid_access_token – 402 An invalid access token was passed to a method.
403

access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
404

no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error.
405

key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed.
406

access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned.
500

internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they’re fixed.
502

throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
503

temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /notifications
Load more endpoints

Schemas

array access_tokens 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "scope": {
        "type": "array",
        "items": {}
      },
      "account_id": {
        "type": "integer"
      },
      "access_token": {
        "type": "string"
      },
      "expires_on_date": {
        "type": "integer"
      }
    }
  }
}
array account_merge 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "merge_date": {
        "type": "integer"
      },
      "new_account_id": {
        "type": "integer"
      },
      "old_account_id": {
        "type": "integer"
      }
    }
  }
}
array answers 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "body": {
        "type": "string"
      },
      "link": {
        "type": "string"
      },
      "tags": {
        "type": "array",
        "items": {}
      },
      "owner": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "score": {
        "type": "integer"
      },
      "title": {
        "type": "string"
      },
      "upvoted": {
        "type": "boolean"
      },
      "accepted": {
        "type": "boolean"
      },
      "can_flag": {
        "type": "boolean"
      },
      "comments": {
        "type": "array",
        "items": {}
      },
      "answer_id": {
        "type": "integer"
      },
      "downvoted": {
        "type": "boolean"
      },
      "share_link": {
        "type": "string"
      },
      "is_accepted": {
        "type": "boolean"
      },
      "last_editor": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "locked_date": {
        "type": "integer"
      },
      "question_id": {
        "type": "integer"
      },
      "body_markdown": {
        "type": "string"
      },
      "comment_count": {
        "type": "integer"
      },
      "creation_date": {
        "type": "integer"
      },
      "up_vote_count": {
        "type": "integer"
      },
      "last_edit_date": {
        "type": "integer"
      },
      "down_vote_count": {
        "type": "integer"
      },
      "last_activity_date": {
        "type": "integer"
      },
      "awarded_bounty_users": {
        "type": "array",
        "items": {}
      },
      "community_owned_date": {
        "type": "integer"
      },
      "awarded_bounty_amount": {
        "type": "integer"
      }
    }
  }
}
array badges 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "link": {
        "type": "string"
      },
      "name": {
        "type": "string"
      },
      "rank": {
        "type": "string"
      },
      "user": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "badge_id": {
        "type": "integer"
      },
      "badge_type": {
        "type": "string"
      },
      "award_count": {
        "type": "integer"
      },
      "description": {
        "type": "string"
      }
    }
  }
}
array comments 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "body": {
        "type": "string"
      },
      "link": {
        "type": "string"
      },
      "owner": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "score": {
        "type": "integer"
      },
      "edited": {
        "type": "boolean"
      },
      "post_id": {
        "type": "integer"
      },
      "upvoted": {
        "type": "boolean"
      },
      "can_flag": {
        "type": "boolean"
      },
      "post_type": {
        "type": "string"
      },
      "comment_id": {
        "type": "integer"
      },
      "body_markdown": {
        "type": "string"
      },
      "creation_date": {
        "type": "integer"
      },
      "reply_to_user": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      }
    }
  }
}
object created_comment 
{
  "type": "object",
  "properties": {
    "body": {
      "type": "string"
    },
    "link": {
      "type": "string"
    },
    "owner": {
      "type": "object",
      "properties": {
        "link": {
          "type": "string"
        },
        "user_id": {
          "type": "integer"
        },
        "user_type": {
          "type": "string"
        },
        "reputation": {
          "type": "integer"
        },
        "accept_rate": {
          "type": "integer"
        },
        "badge_counts": {
          "type": "object",
          "properties": {
            "gold": {
              "type": "integer"
            },
            "bronze": {
              "type": "integer"
            },
            "silver": {
              "type": "integer"
            }
          }
        },
        "display_name": {
          "type": "string"
        },
        "profile_image": {
          "type": "string"
        }
      }
    },
    "score": {
      "type": "integer"
    },
    "edited": {
      "type": "boolean"
    },
    "post_id": {
      "type": "integer"
    },
    "upvoted": {
      "type": "boolean"
    },
    "can_flag": {
      "type": "boolean"
    },
    "post_type": {
      "type": "string"
    },
    "comment_id": {
      "type": "integer"
    },
    "body_markdown": {
      "type": "string"
    },
    "creation_date": {
      "type": "integer"
    },
    "reply_to_user": {
      "type": "object",
      "properties": {
        "link": {
          "type": "string"
        },
        "user_id": {
          "type": "integer"
        },
        "user_type": {
          "type": "string"
        },
        "reputation": {
          "type": "integer"
        },
        "accept_rate": {
          "type": "integer"
        },
        "badge_counts": {
          "type": "object",
          "properties": {
            "gold": {
              "type": "integer"
            },
            "bronze": {
              "type": "integer"
            },
            "silver": {
              "type": "integer"
            }
          }
        },
        "display_name": {
          "type": "string"
        },
        "profile_image": {
          "type": "string"
        }
      }
    }
  }
}
object error 
{
  "type": "object",
  "properties": {
    "error_id": {
      "type": "number"
    },
    "error_name": {
      "type": "string"
    },
    "error_message": {
      "type": "string"
    }
  }
}
array errors 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "error_id": {
        "type": "integer"
      },
      "error_name": {
        "type": "string"
      },
      "description": {
        "type": "string"
      }
    }
  }
}
array events 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "link": {
        "type": "string"
      },
      "excerpt": {
        "type": "string"
      },
      "event_type": {
        "type": "string"
      },
      "creation_date": {
        "type": "integer"
      },
      "the id of the object (answer, comment, question, or user) the event describes": {
        "type": "integer"
      }
    }
  }
}
array filters 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "filter": {
        "type": "string"
      },
      "filter_type": {
        "type": "string"
      },
      "included_fields": {
        "type": "array",
        "items": {}
      }
    }
  }
}
array inbox_items 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "body": {
        "type": "string"
      },
      "link": {
        "type": "string"
      },
      "site": {
        "type": "object",
        "properties": {
          "name": {
            "type": "string"
          },
          "aliases": {
            "type": "array",
            "items": {}
          },
          "styling": {
            "type": "object",
            "properties": {
              "link_color": {
                "type": "string"
              },
              "tag_background_color": {
                "type": "string"
              },
              "tag_foreground_color": {
                "type": "string"
              }
            }
          },
          "audience": {
            "type": "string"
          },
          "icon_url": {
            "type": "string"
          },
          "logo_url": {
            "type": "string"
          },
          "site_url": {
            "type": "string"
          },
          "site_type": {
            "type": "string"
          },
          "site_state": {
            "type": "string"
          },
          "favicon_url": {
            "type": "string"
          },
          "launch_date": {
            "type": "integer"
          },
          "related_sites": {
            "type": "array",
            "items": {}
          },
          "open_beta_date": {
            "type": "integer"
          },
          "twitter_account": {
            "type": "string"
          },
          "closed_beta_date": {
            "type": "integer"
          },
          "api_site_parameter": {
            "type": "string"
          },
          "markdown_extensions": {
            "type": "array",
            "items": {}
          },
          "high_resolution_icon_url": {
            "type": "string"
          }
        }
      },
      "title": {
        "type": "string"
      },
      "answer_id": {
        "type": "integer"
      },
      "is_unread": {
        "type": "boolean"
      },
      "item_type": {
        "type": "string"
      },
      "comment_id": {
        "type": "integer"
      },
      "question_id": {
        "type": "integer"
      },
      "creation_date": {
        "type": "integer"
      }
    }
  }
}
object info_object 
{
  "type": "object",
  "properties": {
    "site": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        },
        "aliases": {
          "type": "array",
          "items": {}
        },
        "styling": {
          "type": "object",
          "properties": {
            "link_color": {
              "type": "string"
            },
            "tag_background_color": {
              "type": "string"
            },
            "tag_foreground_color": {
              "type": "string"
            }
          }
        },
        "audience": {
          "type": "string"
        },
        "icon_url": {
          "type": "string"
        },
        "logo_url": {
          "type": "string"
        },
        "site_url": {
          "type": "string"
        },
        "site_type": {
          "type": "string"
        },
        "site_state": {
          "type": "string"
        },
        "favicon_url": {
          "type": "string"
        },
        "launch_date": {
          "type": "integer"
        },
        "related_sites": {
          "type": "array",
          "items": {}
        },
        "open_beta_date": {
          "type": "integer"
        },
        "twitter_account": {
          "type": "string"
        },
        "closed_beta_date": {
          "type": "integer"
        },
        "api_site_parameter": {
          "type": "string"
        },
        "markdown_extensions": {
          "type": "array",
          "items": {}
        },
        "high_resolution_icon_url": {
          "type": "string"
        }
      }
    },
    "total_users": {
      "type": "integer"
    },
    "total_votes": {
      "type": "integer"
    },
    "api_revision": {
      "type": "string"
    },
    "total_badges": {
      "type": "integer"
    },
    "total_answers": {
      "type": "integer"
    },
    "total_accepted": {
      "type": "integer"
    },
    "total_comments": {
      "type": "integer"
    },
    "total_questions": {
      "type": "integer"
    },
    "new_active_users": {
      "type": "integer"
    },
    "total_unanswered": {
      "type": "integer"
    },
    "badges_per_minute": {
      "type": "number"
    },
    "answers_per_minute": {
      "type": "number"
    },
    "questions_per_minute": {
      "type": "number"
    }
  }
}
array network_users 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "user_id": {
        "type": "integer"
      },
      "site_url": {
        "type": "string"
      },
      "site_name": {
        "type": "string"
      },
      "user_type": {
        "type": "string"
      },
      "account_id": {
        "type": "integer"
      },
      "reputation": {
        "type": "integer"
      },
      "top_answers": {
        "type": "array",
        "items": {}
      },
      "answer_count": {
        "type": "integer"
      },
      "badge_counts": {
        "type": "object",
        "properties": {
          "gold": {
            "type": "integer"
          },
          "bronze": {
            "type": "integer"
          },
          "silver": {
            "type": "integer"
          }
        }
      },
      "creation_date": {
        "type": "integer"
      },
      "top_questions": {
        "type": "array",
        "items": {}
      },
      "question_count": {
        "type": "integer"
      },
      "last_access_date": {
        "type": "integer"
      }
    }
  }
}
array notifications 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "body": {
        "type": "string"
      },
      "site": {
        "type": "object",
        "properties": {
          "name": {
            "type": "string"
          },
          "aliases": {
            "type": "array",
            "items": {}
          },
          "styling": {
            "type": "object",
            "properties": {
              "link_color": {
                "type": "string"
              },
              "tag_background_color": {
                "type": "string"
              },
              "tag_foreground_color": {
                "type": "string"
              }
            }
          },
          "audience": {
            "type": "string"
          },
          "icon_url": {
            "type": "string"
          },
          "logo_url": {
            "type": "string"
          },
          "site_url": {
            "type": "string"
          },
          "site_type": {
            "type": "string"
          },
          "site_state": {
            "type": "string"
          },
          "favicon_url": {
            "type": "string"
          },
          "launch_date": {
            "type": "integer"
          },
          "related_sites": {
            "type": "array",
            "items": {}
          },
          "open_beta_date": {
            "type": "integer"
          },
          "twitter_account": {
            "type": "string"
          },
          "closed_beta_date": {
            "type": "integer"
          },
          "api_site_parameter": {
            "type": "string"
          },
          "markdown_extensions": {
            "type": "array",
            "items": {}
          },
          "high_resolution_icon_url": {
            "type": "string"
          }
        }
      },
      "post_id": {
        "type": "integer"
      },
      "is_unread": {
        "type": "boolean"
      },
      "creation_date": {
        "type": "integer"
      },
      "notification_type": {
        "type": "string"
      }
    }
  }
}
array posts 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "body": {
        "type": "string"
      },
      "link": {
        "type": "string"
      },
      "owner": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "score": {
        "type": "integer"
      },
      "title": {
        "type": "string"
      },
      "post_id": {
        "type": "integer"
      },
      "upvoted": {
        "type": "boolean"
      },
      "comments": {
        "type": "array",
        "items": {}
      },
      "downvoted": {
        "type": "boolean"
      },
      "post_type": {
        "type": "string"
      },
      "share_link": {
        "type": "string"
      },
      "last_editor": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "body_markdown": {
        "type": "string"
      },
      "comment_count": {
        "type": "integer"
      },
      "creation_date": {
        "type": "integer"
      },
      "up_vote_count": {
        "type": "integer"
      },
      "last_edit_date": {
        "type": "integer"
      },
      "down_vote_count": {
        "type": "integer"
      },
      "last_activity_date": {
        "type": "integer"
      }
    }
  }
}
array privileges 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "reputation": {
        "type": "integer"
      },
      "description": {
        "type": "string"
      },
      "short_description": {
        "type": "string"
      }
    }
  }
}
array question_timeline_events 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "user": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "owner": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "post_id": {
        "type": "integer"
      },
      "comment_id": {
        "type": "integer"
      },
      "question_id": {
        "type": "integer"
      },
      "creation_date": {
        "type": "integer"
      },
      "revision_guid": {
        "type": "string"
      },
      "timeline_type": {
        "type": "string"
      },
      "up_vote_count": {
        "type": "integer"
      },
      "down_vote_count": {
        "type": "integer"
      }
    }
  }
}
array questions 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "body": {
        "type": "string"
      },
      "link": {
        "type": "string"
      },
      "tags": {
        "type": "array",
        "items": {}
      },
      "owner": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "score": {
        "type": "integer"
      },
      "title": {
        "type": "string"
      },
      "notice": {
        "type": "object",
        "properties": {
          "body": {
            "type": "string"
          },
          "creation_date": {
            "type": "integer"
          },
          "owner_user_id": {
            "type": "integer"
          }
        }
      },
      "answers": {
        "type": "array",
        "items": {}
      },
      "upvoted": {
        "type": "boolean"
      },
      "can_flag": {
        "type": "boolean"
      },
      "comments": {
        "type": "array",
        "items": {}
      },
      "can_close": {
        "type": "boolean"
      },
      "downvoted": {
        "type": "boolean"
      },
      "favorited": {
        "type": "boolean"
      },
      "share_link": {
        "type": "string"
      },
      "view_count": {
        "type": "integer"
      },
      "bounty_user": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "closed_date": {
        "type": "integer"
      },
      "is_answered": {
        "type": "boolean"
      },
      "last_editor": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "locked_date": {
        "type": "integer"
      },
      "migrated_to": {
        "type": "object",
        "properties": {
          "on_date": {
            "type": "integer"
          },
          "other_site": {
            "type": "object",
            "properties": {
              "name": {
                "type": "string"
              },
              "aliases": {
                "type": "array",
                "items": {}
              },
              "styling": {
                "type": "object",
                "properties": {
                  "link_color": {
                    "type": "string"
                  },
                  "tag_background_color": {
                    "type": "string"
                  },
                  "tag_foreground_color": {
                    "type": "string"
                  }
                }
              },
              "audience": {
                "type": "string"
              },
              "icon_url": {
                "type": "string"
              },
              "logo_url": {
                "type": "string"
              },
              "site_url": {
                "type": "string"
              },
              "site_type": {
                "type": "string"
              },
              "site_state": {
                "type": "string"
              },
              "favicon_url": {
                "type": "string"
              },
              "launch_date": {
                "type": "integer"
              },
              "related_sites": {
                "type": "array",
                "items": {}
              },
              "open_beta_date": {
                "type": "integer"
              },
              "twitter_account": {
                "type": "string"
              },
              "closed_beta_date": {
                "type": "integer"
              },
              "api_site_parameter": {
                "type": "string"
              },
              "markdown_extensions": {
                "type": "array",
                "items": {}
              },
              "high_resolution_icon_url": {
                "type": "string"
              }
            }
          },
          "question_id": {
            "type": "integer"
          }
        }
      },
      "question_id": {
        "type": "integer"
      },
      "answer_count": {
        "type": "integer"
      },
      "body_markdown": {
        "type": "string"
      },
      "bounty_amount": {
        "type": "integer"
      },
      "closed_reason": {
        "type": "string"
      },
      "comment_count": {
        "type": "integer"
      },
      "creation_date": {
        "type": "integer"
      },
      "migrated_from": {
        "type": "object",
        "properties": {
          "on_date": {
            "type": "integer"
          },
          "other_site": {
            "type": "object",
            "properties": {
              "name": {
                "type": "string"
              },
              "aliases": {
                "type": "array",
                "items": {}
              },
              "styling": {
                "type": "object",
                "properties": {
                  "link_color": {
                    "type": "string"
                  },
                  "tag_background_color": {
                    "type": "string"
                  },
                  "tag_foreground_color": {
                    "type": "string"
                  }
                }
              },
              "audience": {
                "type": "string"
              },
              "icon_url": {
                "type": "string"
              },
              "logo_url": {
                "type": "string"
              },
              "site_url": {
                "type": "string"
              },
              "site_type": {
                "type": "string"
              },
              "site_state": {
                "type": "string"
              },
              "favicon_url": {
                "type": "string"
              },
              "launch_date": {
                "type": "integer"
              },
              "related_sites": {
                "type": "array",
                "items": {}
              },
              "open_beta_date": {
                "type": "integer"
              },
              "twitter_account": {
                "type": "string"
              },
              "closed_beta_date": {
                "type": "integer"
              },
              "api_site_parameter": {
                "type": "string"
              },
              "markdown_extensions": {
                "type": "array",
                "items": {}
              },
              "high_resolution_icon_url": {
                "type": "string"
              }
            }
          },
          "question_id": {
            "type": "integer"
          }
        }
      },
      "up_vote_count": {
        "type": "integer"
      },
      "closed_details": {
        "type": "object",
        "properties": {
          "reason": {
            "type": "string"
          },
          "on_hold": {
            "type": "boolean"
          },
          "by_users": {
            "type": "array",
            "items": {}
          },
          "description": {
            "type": "string"
          },
          "original_questions": {
            "type": "array",
            "items": {}
          }
        }
      },
      "favorite_count": {
        "type": "integer"
      },
      "last_edit_date": {
        "type": "integer"
      },
      "protected_date": {
        "type": "integer"
      },
      "down_vote_count": {
        "type": "integer"
      },
      "close_vote_count": {
        "type": "integer"
      },
      "delete_vote_count": {
        "type": "integer"
      },
      "reopen_vote_count": {
        "type": "integer"
      },
      "accepted_answer_id": {
        "type": "integer"
      },
      "bounty_closes_date": {
        "type": "integer"
      },
      "last_activity_date": {
        "type": "integer"
      },
      "community_owned_date": {
        "type": "integer"
      }
    }
  }
}
array reputation_changes 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "link": {
        "type": "string"
      },
      "title": {
        "type": "string"
      },
      "on_date": {
        "type": "integer"
      },
      "post_id": {
        "type": "integer"
      },
      "user_id": {
        "type": "integer"
      },
      "post_type": {
        "type": "string"
      },
      "vote_type": {
        "type": "string"
      },
      "reputation_change": {
        "type": "integer"
      }
    }
  }
}
array reputation_history 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "post_id": {
        "type": "integer"
      },
      "user_id": {
        "type": "integer"
      },
      "creation_date": {
        "type": "integer"
      },
      "reputation_change": {
        "type": "integer"
      },
      "reputation_history_type": {
        "type": "string"
      }
    }
  }
}
array reputation_objects 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "link": {
        "type": "string"
      },
      "title": {
        "type": "string"
      },
      "on_date": {
        "type": "integer"
      },
      "post_id": {
        "type": "integer"
      },
      "user_id": {
        "type": "integer"
      },
      "post_type": {
        "type": "string"
      },
      "vote_type": {
        "type": "string"
      },
      "reputation_change": {
        "type": "integer"
      }
    }
  }
}
array revisions 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "body": {
        "type": "string"
      },
      "tags": {
        "type": "array",
        "items": {}
      },
      "user": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "title": {
        "type": "string"
      },
      "comment": {
        "type": "string"
      },
      "post_id": {
        "type": "integer"
      },
      "last_body": {
        "type": "string"
      },
      "last_tags": {
        "type": "array",
        "items": {}
      },
      "post_type": {
        "type": "string"
      },
      "last_title": {
        "type": "string"
      },
      "is_rollback": {
        "type": "boolean"
      },
      "creation_date": {
        "type": "integer"
      },
      "revision_guid": {
        "type": "string"
      },
      "revision_type": {
        "type": "string"
      },
      "revision_number": {
        "type": "integer"
      },
      "set_community_wiki": {
        "type": "boolean"
      }
    }
  }
}
object single_filter 
{
  "type": "object",
  "properties": {
    "filter": {
      "type": "string"
    },
    "filter_type": {
      "type": "string"
    },
    "included_fields": {
      "type": "array",
      "items": {}
    }
  }
}
array sites 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "name": {
        "type": "string"
      },
      "aliases": {
        "type": "array",
        "items": {}
      },
      "styling": {
        "type": "object",
        "properties": {
          "link_color": {
            "type": "string"
          },
          "tag_background_color": {
            "type": "string"
          },
          "tag_foreground_color": {
            "type": "string"
          }
        }
      },
      "audience": {
        "type": "string"
      },
      "icon_url": {
        "type": "string"
      },
      "logo_url": {
        "type": "string"
      },
      "site_url": {
        "type": "string"
      },
      "site_type": {
        "type": "string"
      },
      "site_state": {
        "type": "string"
      },
      "favicon_url": {
        "type": "string"
      },
      "launch_date": {
        "type": "integer"
      },
      "related_sites": {
        "type": "array",
        "items": {}
      },
      "open_beta_date": {
        "type": "integer"
      },
      "twitter_account": {
        "type": "string"
      },
      "closed_beta_date": {
        "type": "integer"
      },
      "api_site_parameter": {
        "type": "string"
      },
      "markdown_extensions": {
        "type": "array",
        "items": {}
      },
      "high_resolution_icon_url": {
        "type": "string"
      }
    }
  }
}
array suggested-edits 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "body": {
        "type": "string"
      },
      "tags": {
        "type": "array",
        "items": {}
      },
      "title": {
        "type": "string"
      },
      "comment": {
        "type": "string"
      },
      "post_id": {
        "type": "integer"
      },
      "post_type": {
        "type": "string"
      },
      "approval_date": {
        "type": "integer"
      },
      "creation_date": {
        "type": "integer"
      },
      "proposing_user": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "rejection_date": {
        "type": "integer"
      },
      "suggested_edit_id": {
        "type": "integer"
      }
    }
  }
}
array tag_score_objects 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "user": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "score": {
        "type": "integer"
      },
      "post_count": {
        "type": "integer"
      }
    }
  }
}
array tag_synonyms 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "to_tag": {
        "type": "string"
      },
      "from_tag": {
        "type": "string"
      },
      "applied_count": {
        "type": "integer"
      },
      "creation_date": {
        "type": "integer"
      },
      "last_applied_date": {
        "type": "integer"
      }
    }
  }
}
array tag_wikis 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "body": {
        "type": "string"
      },
      "excerpt": {
        "type": "string"
      },
      "tag_name": {
        "type": "string"
      },
      "last_body_editor": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "body_last_edit_date": {
        "type": "integer"
      },
      "last_excerpt_editor": {
        "type": "object",
        "properties": {
          "link": {
            "type": "string"
          },
          "user_id": {
            "type": "integer"
          },
          "user_type": {
            "type": "string"
          },
          "reputation": {
            "type": "integer"
          },
          "accept_rate": {
            "type": "integer"
          },
          "badge_counts": {
            "type": "object",
            "properties": {
              "gold": {
                "type": "integer"
              },
              "bronze": {
                "type": "integer"
              },
              "silver": {
                "type": "integer"
              }
            }
          },
          "display_name": {
            "type": "string"
          },
          "profile_image": {
            "type": "string"
          }
        }
      },
      "excerpt_last_edit_date": {
        "type": "integer"
      }
    }
  }
}
array tags 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "name": {
        "type": "string"
      },
      "count": {
        "type": "integer"
      },
      "user_id": {
        "type": "integer"
      },
      "synonyms": {
        "type": "array",
        "items": {}
      },
      "is_required": {
        "type": "boolean"
      },
      "has_synonyms": {
        "type": "boolean"
      },
      "is_moderator_only": {
        "type": "boolean"
      },
      "last_activity_date": {
        "type": "integer"
      }
    }
  }
}
array top_tag_objects 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "user_id": {
        "type": "integer"
      },
      "tag_name": {
        "type": "string"
      },
      "answer_count": {
        "type": "integer"
      },
      "answer_score": {
        "type": "integer"
      },
      "question_count": {
        "type": "integer"
      },
      "question_score": {
        "type": "integer"
      }
    }
  }
}
object user 
{
  "type": "object",
  "properties": {
    "age": {
      "type": "integer"
    },
    "link": {
      "type": "string"
    },
    "user_id": {
      "type": "integer"
    },
    "about_me": {
      "type": "string"
    },
    "location": {
      "type": "string"
    },
    "user_type": {
      "type": "string"
    },
    "account_id": {
      "type": "integer"
    },
    "reputation": {
      "type": "integer"
    },
    "view_count": {
      "type": "integer"
    },
    "accept_rate": {
      "type": "integer"
    },
    "is_employee": {
      "type": "boolean"
    },
    "website_url": {
      "type": "string"
    },
    "answer_count": {
      "type": "integer"
    },
    "badge_counts": {
      "type": "object",
      "properties": {
        "gold": {
          "type": "integer"
        },
        "bronze": {
          "type": "integer"
        },
        "silver": {
          "type": "integer"
        }
      }
    },
    "display_name": {
      "type": "string"
    },
    "creation_date": {
      "type": "integer"
    },
    "profile_image": {
      "type": "string"
    },
    "up_vote_count": {
      "type": "integer"
    },
    "question_count": {
      "type": "integer"
    },
    "down_vote_count": {
      "type": "integer"
    },
    "last_access_date": {
      "type": "integer"
    },
    "last_modified_date": {
      "type": "integer"
    },
    "timed_penalty_date": {
      "type": "integer"
    },
    "reputation_change_day": {
      "type": "integer"
    },
    "reputation_change_week": {
      "type": "integer"
    },
    "reputation_change_year": {
      "type": "integer"
    },
    "reputation_change_month": {
      "type": "integer"
    },
    "reputation_change_quarter": {
      "type": "integer"
    }
  }
}
array user_timeline_objects 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "link": {
        "type": "string"
      },
      "title": {
        "type": "string"
      },
      "detail": {
        "type": "string"
      },
      "post_id": {
        "type": "integer"
      },
      "user_id": {
        "type": "integer"
      },
      "badge_id": {
        "type": "integer"
      },
      "post_type": {
        "type": "string"
      },
      "comment_id": {
        "type": "integer"
      },
      "creation_date": {
        "type": "integer"
      },
      "timeline_type": {
        "type": "string"
      },
      "suggested_edit_id": {
        "type": "integer"
      }
    }
  }
}
array users 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "age": {
        "type": "integer"
      },
      "link": {
        "type": "string"
      },
      "user_id": {
        "type": "integer"
      },
      "about_me": {
        "type": "string"
      },
      "location": {
        "type": "string"
      },
      "user_type": {
        "type": "string"
      },
      "account_id": {
        "type": "integer"
      },
      "reputation": {
        "type": "integer"
      },
      "view_count": {
        "type": "integer"
      },
      "accept_rate": {
        "type": "integer"
      },
      "is_employee": {
        "type": "boolean"
      },
      "website_url": {
        "type": "string"
      },
      "answer_count": {
        "type": "integer"
      },
      "badge_counts": {
        "type": "object",
        "properties": {
          "gold": {
            "type": "integer"
          },
          "bronze": {
            "type": "integer"
          },
          "silver": {
            "type": "integer"
          }
        }
      },
      "display_name": {
        "type": "string"
      },
      "creation_date": {
        "type": "integer"
      },
      "profile_image": {
        "type": "string"
      },
      "up_vote_count": {
        "type": "integer"
      },
      "question_count": {
        "type": "integer"
      },
      "down_vote_count": {
        "type": "integer"
      },
      "last_access_date": {
        "type": "integer"
      },
      "last_modified_date": {
        "type": "integer"
      },
      "timed_penalty_date": {
        "type": "integer"
      },
      "reputation_change_day": {
        "type": "integer"
      },
      "reputation_change_week": {
        "type": "integer"
      },
      "reputation_change_year": {
        "type": "integer"
      },
      "reputation_change_month": {
        "type": "integer"
      },
      "reputation_change_quarter": {
        "type": "integer"
      }
    }
  }
}
array write_permissions 
{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "can_add": {
        "type": "boolean"
      },
      "user_id": {
        "type": "integer"
      },
      "can_edit": {
        "type": "boolean"
      },
      "can_delete": {
        "type": "boolean"
      },
      "object_type": {
        "type": "string"
      },
      "max_daily_actions": {
        "type": "integer"
      },
      "min_seconds_between_actions": {
        "type": "integer"
      }
    }
  }
}