/notifications/unread
Returns a user’s unread notifications.
This method requires an access_token, with a scope containing “read_inbox”.
This method returns a list of notifications.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /notifications/unread
/me/write-permissions
Returns the write permissions a user has via the api, given an access token.
The Stack Exchange API gives users the ability to create, edit, and delete certain types. This method returns whether the passed user is capable of performing those actions at all, as well as how many times a day they can.
This method does not consider the user’s current quota (ie. if they’ve already exhausted it for today) nor any additional restrictions on write access, such as editing deleted comments.
This method returns a list of write_permissions.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/write-permissions
/posts
Fetches all posts (questions and answers) on the site.
In many ways this method is the union of /questions and /answers, returning both sets of data albeit only the common fields.
Most applications should use the question or answer specific methods, but /posts is available for those rare cases where any activity is of intereset. Examples of such queries would be: “all posts on Jan. 1st 2011” or “top 10 posts by score of all time”.
The sorts accepted by this method operate on the follow fields of the post object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of posts.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /posts
/posts/{ids}
Fetches a set of posts by ids.
This method is meant for grabbing an object when unsure whether an id identifies a question or an answer. This is most common with user entered data.
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for post_id, answer_id, or question_id on post, answer, and question objects respectively.
The sorts accepted by this method operate on the follow fields of the post object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of posts.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /posts/{ids}
/posts/{ids}/comments
Gets the comments on the posts identified in ids, regardless of the type of the posts.
This method is meant for cases when you are unsure of the type of the post id provided. Generally, this would be due to obtaining the post id directly from a user.
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for post_id, answer_id, or question_id on post, answer, and question objects respectively.
The sorts accepted by this method operate on the follow fields of the comment object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = creation => date |
| min | query | optional | string | sort = creation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /posts/{ids}/comments
/posts/{ids}/revisions
Returns edit revisions for the posts identified in ids.
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for post_id, answer_id, or question_id on post, answer, and question objects respectively.
This method returns a list of revisions.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /posts/{ids}/revisions
/posts/{ids}/suggested-edits
Returns suggsted edits on the posts identified in ids.
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for post_id, answer_id, or question_id on post, answer, and question objects respectively.
This method returns a list of suggested-edits.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = creation => date |
| min | query | optional | string | sort = creation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /posts/{ids}/suggested-edits
/posts/{id}/comments/add
Create a new comment.
Use an access_token with write_access to create a new comment on a post.
This method returns the created comment.
| 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). #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 | — |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
POST /posts/{id}/comments/add
/me/privileges
Returns the privileges the user identified by access_token has.
This method returns a list of privileges.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/privileges
/privileges
Returns the earnable privileges on a site.
Privileges define abilities a user can earn (via reputation) on any Stack Exchange site.
While fairly stable, over time they do change. New ones are introduced with new features, and the reputation requirements change as a site matures.
This method returns a list of privileges.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /privileges
/search
Searches a site for any questions which fit the given criteria.
This method is intentionally quite limited. For more general searching, you should use a proper internet search engine restricted to the domain of the site in question.
At least one of tagged or intitle must be set on this method. nottagged is only used if tagged is also set, for performance reasons.
tagged and nottagged are semi-colon delimited list of tags. At least 1 tag in tagged will be on each returned question if it is passed, making it the OR equivalent of the AND version of tagged on /questions.
The sorts accepted by this method operate on the follow fields of the question object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
| intitle | query | optional | string | — |
| nottagged | query | optional | string | String list (semicolon delimited). |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /search
/similar
Returns questions which are similar to a hypothetical one based on a title and tag combination.
This method is roughly equivalent to a site’s related questions suggestion on the ask page.
This method is useful for correlating data outside of a Stack Exchange site with similar content within one.
Note that title must always be passed as a parameter. tagged and nottagged are optional, semi-colon delimited lists of tags.
If tagged is passed it is treated as a preference, there is no guarantee that questions returned will have any of those tags. nottagged is treated as a requirement, no questions will be returned with those tags.
The sorts accepted by this method operate on the follow fields of the question object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
| nottagged | query | optional | string | String list (semicolon delimited). |
| title | query | optional | string | — |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /similar
/me/questions
Returns the questions owned by the user associated with the given access_token.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/questions
/me/questions/featured
Returns the questions that have active bounties offered by the user associated with the given access_token.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/questions/featured
/me/questions/unaccepted
Returns the questions owned by the user associated with the given access_token that have no accepted answer.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/questions/unaccepted
/questions
Gets all the questions on the site.
This method allows you make fairly flexible queries across the entire corpus of questions on a site. For example, getting all questions asked in the the week of Jan 1st 2011 with scores of 10 or more is a single query with parameters sort=votes&min=10&fromdate=1293840000&todate=1294444800.
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:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /questions
/questions/featured
Returns all the questions with active bounties in the system.
The sorts accepted by this method operate on the follow fields of the question object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /questions/featured
/questions/{ids}
Returns the questions identified in {ids}.
This is most useful for fetching fresh data when maintaining a cache of question ids, or polling for changes.
{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 question object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /questions/{ids}
/questions/{ids}/linked
Gets questions which link to those questions identified in {ids}.
This method only considers questions that are linked within a site, and will never return questions from another Stack Exchange site.
A question is considered “linked” when it explicitly includes a hyperlink to another question, there are no other heuristics.
{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 question object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /questions/{ids}/linked
/questions/{ids}/related
Returns questions that the site considers related to those identified in {ids}.
The algorithm for determining if questions are related is not documented, and subject to change at any time. Futhermore, these values are very heavily cached, and may not update immediately after a question has been editted. It is also not guaranteed that a question will be considered related to any number (even non-zero) of questions, and a consumer should be able to handle a variable number of returned questions.
{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 question object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /questions/{ids}/related
/questions/{ids}/timeline
Returns a subset of the events that have happened to the questions identified in id.
This provides data similar to that found on a question’s timeline page.
Voting data is scrubbed to deter inferencing of voter identity.
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for question_id on question objects.
This method returns a list of question timeline events.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /questions/{ids}/timeline
/me/reputation
Returns the reputation changed for the user associated with the given access_token.
This method returns a list of reputation changes.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/reputation
/me/reputation-history
Returns user’s public reputation history.
This method returns a list of reputation_history.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/reputation-history
/me/reputation-history/full
Returns user’s full reputation history, including private events.
This method requires an access_token, with a scope containing “private_info”.
This method returns a list of reputation_history.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/reputation-history/full
/revisions/{ids}
Returns edit revisions identified by ids in {ids}.
{ids} can contain up to 20 semicolon delimited ids, to find ids programatically look for revision_guid on revision objects. Note that unlike most other id types in the API, revision_guid is a string.
This method returns a list of revisions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Guid 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /revisions/{ids}
/search/advanced
Searches a site for any questions which fit the given criteria.
Search criteria are expressed using the following parameters:
At least one additional parameter must be set if nottagged is set, for performance reasons.
The sorts accepted by this method operate on the follow fields of the question object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
| accepted | query | optional | boolean | — |
| answers | query | optional | integer | — |
| body | query | optional | string | — |
| closed | query | optional | boolean | — |
| migrated | query | optional | boolean | — |
| notice | query | optional | boolean | — |
| nottagged | query | optional | string | String list (semicolon delimited). |
| q | query | optional | string | — |
| title | query | optional | string | — |
| url | query | optional | string | — |
| user | query | optional | integer | — |
| views | query | optional | integer | — |
| wiki | query | optional | boolean | — |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /search/advanced
/sites
Returns all sites in the network.
This method allows for discovery of new sites, and changes to existing ones. Be aware that unlike normal API methods, this method should be fetched very infrequently, it is very unusual for these values to change more than once on any given day. It is suggested that you cache its return for at least one day, unless your app encounters evidence that it has changed (such as from the /info method).
The pagesize parameter for this method is unbounded, in acknowledgement that for many applications repeatedly fetching from /sites would complicate start-up tasks needlessly.
This method returns a list of sites.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /sites
/me/tags
Returns the tags the user identified by the access_token passed is active in.
This method returns a list of tags.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | — |
| max | query | optional | string | sort = popular => number |
| min | query | optional | string | sort = popular => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/tags
/me/tags/{tags}/top-questions
Returns the top 30 questions the user associated with the given access_token has posted in response to questions with the given tags.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tags | path | required | string | String list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
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-questions
/me/top-question-tags
Returns the user identified by access_token’s top 30 tags by question score.
This method returns a list of top tag objects.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/top-question-tags
/tags/moderator-only
Returns the tags found on a site that only moderators can use.
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:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| inname | query | optional | string | — |
| order | query | optional | string | — |
| max | query | optional | string | sort = popular => number |
| min | query | optional | string | sort = popular => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags/moderator-only
/tags/required
Returns the tags found on a site that fulfill required tag constraints on questions.
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:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| inname | query | optional | string | — |
| order | query | optional | string | — |
| max | query | optional | string | sort = popular => number |
| min | query | optional | string | sort = popular => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags/required
/tags/synonyms
Returns all tag synonyms found a site.
When searching for synonyms of specific tags, it is better to use /tags/{tags}/synonyms over this method.
The sorts accepted by this method operate on the follow fields of the tag_synonym object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of tag_synonyms.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | — |
| max | query | optional | string | sort = creation => date |
| min | query | optional | string | sort = creation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags/synonyms
/tags/{tags}/faq
Returns the frequently asked questions for the given set of tags in {tags}.
For a question to be returned, it must have all the tags in {tags} and be considered “frequently asked”. The exact algorithm for determining whether a question is considered a FAQ is subject to change at any time.
{tags} can contain up to 5 individual tags per request.
This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tags | 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags/{tags}/faq
/tags/{tags}/info
Returns tag objects representing the tags in {tags} found on the site.
This method diverges from the standard naming patterns to avoid to conflicting with existing methods, due to the free form nature of tag names.
This method returns a list of tags.
The sorts accepted by this method operate on the follow fields of the tag object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tags | path | required | string | String list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = popular => number |
| min | query | optional | string | sort = popular => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags/{tags}/info
/tags/{tags}/related
Returns the tags that are most related to those in {tags}.
Including multiple tags in {tags} is equivalent to asking for “tags related to tag #1 and tag #2” not “tags related to tag #1 or tag #2”.
count on tag objects returned is the number of question with that tag that also share all those in {tags}.
{tags} can contain up to 4 individual tags per request.
This method returns a list of tags.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tags | 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags/{tags}/related
/tags/{tags}/synonyms
Gets all the synonyms that point to the tags identified in {tags}. If you’re looking to discover all the tag synonyms on a site, use the /tags/synonyms methods instead of call this method on all tags.
{tags} can contain up to 20 individual tags per request.
The sorts accepted by this method operate on the follow fields of the tag_synonym object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of tag synonyms.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tags | path | required | string | String list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = creation => date |
| min | query | optional | string | sort = creation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags/{tags}/synonyms
/tags/{tags}/wikis
Returns the wikis that go with the given set of tags in {tags}.
Be aware that not all tags have wikis.
{tags} can contain up to 20 individual tags per request.
This method returns a list of tag wikis.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tags | 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags/{tags}/wikis
/tags/{tag}/top-askers/{period}
Returns the top 30 askers 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.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /tags/{tag}/top-askers/{period}
/me/timeline
Returns a subset of the actions the user identified by the passed access_token has taken on the site.
This method returns a list of user timeline objects.
| 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me/timeline
/me
Returns the user associated with the passed access_token.
This method returns a user.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | — |
| max | query | optional | string | sort = reputation => number |
| min | query | optional | string | sort = reputation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /me
/users
Returns all users on a site.
This method returns a list of users.
The sorts accepted by this method operate on the follow fields of the user object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
The inname parameter lets consumers filter the results down to just those users with a certain substring in their display name. For example, inname=kevin will return all users with both users named simply “Kevin” or those with Kevin as one of (or part of) their names; such as “Kevin Montrose”.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| inname | query | optional | string | — |
| order | query | optional | string | — |
| max | query | optional | string | sort = reputation => number |
| min | query | optional | string | sort = reputation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /users
/users/moderators
Gets those users on a site who can exercise moderation powers.
Note, employees of Stack Exchange Inc. will be returned if they have been granted moderation powers on a site even if they have never been appointed or elected explicitly. This method checks abilities, not the manner in which they were obtained.
The sorts accepted by this method operate on the follow fields of the user object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of users.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | — |
| max | query | optional | string | sort = reputation => number |
| min | query | optional | string | sort = reputation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /users/moderators
/users/moderators/elected
Returns those users on a site who both have moderator powers, and were actually elected.
This method excludes Stack Exchange Inc. employees, unless they were actually elected moderators on a site (which can only have happened prior to their employment).
The sorts accepted by this method operate on the follow fields of the user object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of users.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | — |
| max | query | optional | string | sort = reputation => number |
| min | query | optional | string | sort = reputation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /users/moderators/elected
/users/{ids}
Gets the users identified in ids in {ids}.
Typically this method will be called to fetch user profiles when you have obtained user ids from some other source, such as /questions.
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for user_id on user or shallow_user objects.
The sorts accepted by this method operate on the follow fields of the user object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of users.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = reputation => number |
| min | query | optional | string | sort = reputation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /users/{ids}
/users/{ids}/answers
Returns the answers the users in {ids} have posted.
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for user_id on user or shallow_user objects.
The sorts accepted by this method operate on the follow fields of the answer object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of answers.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = activity => date |
| min | query | optional | string | sort = activity => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /users/{ids}/answers
/users/{ids}/associated
Returns all of a user’s associated accounts, given their account_ids in {ids}.
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for account_id on user objects.
This method returns a list of network_users.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /users/{ids}/associated
/users/{ids}/badges
Get the badges the users in {ids} have earned.
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 a user has 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 user_id on user or shallow_user objects.
This method returns a list of badges.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = rank => string |
| min | query | optional | string | sort = rank => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /users/{ids}/badges
/users/{ids}/comments
Get the comments posted by users in {ids}.
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for user_id on user or shallow_user objects.
The sorts accepted by this method operate on the follow fields of the comment object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | — |
| max | query | optional | string | sort = creation => date |
| min | query | optional | string | sort = creation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /users/{ids}/comments
/users/{ids}/comments/{toid}
Get the comments that the users in {ids} have posted in reply to the single user identified in {toid}.
This method is useful for extracting conversations, especially over time or across multiple posts.
{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for user_id on user or shallow_user objects. {toid} can contain only 1 id, found in the same manner as those in {ids}.
The sorts accepted by this method operate on the follow fields of the comment object:
It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| toid | path | required | integer | — |
| order | query | optional | string | — |
| max | query | optional | string | sort = creation => date |
| min | query | optional | string | sort = creation => 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). #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. |
OK
bad_parameter – 400 An invalid parameter was passed, this includes even “high level” parameters like key or site.
access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.
invalid_access_token – 402 An invalid access token was passed to a method.
access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.
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.
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.
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.
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.
throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.
temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.
GET /users/{ids}/comments/{toid}