Query structured spec data via REST or MCP. Get exactly what your agent needs.
https://api.stackexchange.com/2.0
/access-tokens/{accessTokens}
Reads the properties for a set of access tokens. {accessTokens} can contain up to 20 access tokens. These are obtained by authenticating a user using OAuth 2.0. This method returns a list of access_tokens.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| accessTokens | path | required | string | String list (semicolon delimited). |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
GET /access-tokens/{accessTokens}
/access-tokens/{accessTokens}/invalidate
Immediately expires the access tokens passed. This method is meant to allow an application to discard any active access tokens it no longer needs. {accessTokens} can contain up to 20 access tokens. These are obtained by authenticating a user using OAuth 2.0. This method returns a list of access_tokens.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| accessTokens | path | required | string | String list (semicolon delimited). |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
GET /access-tokens/{accessTokens}/invalidate
/apps/{accessTokens}/de-authenticate
Passing valid access_tokens to this method causes the application that created them to be de-authorized by the user associated with each access_token. This will remove the application from their apps tab, and cause all other existing access_tokens to be destroyed. This method is meant for uninstalling applications, recovering from access_token leaks, or simply as a stronger form of /access-tokens/{accessTokens}/invalidate. Nothing prevents a user from re-authenticate to an application that has de-authenticated itself, the user will be prompted to approve the application again however. {accessTokens} can contain up to 20 access tokens. These are obtained by authenticating a user using OAuth 2.0. This method returns a list of access_tokens.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| accessTokens | path | required | string | String list (semicolon delimited). |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
GET /apps/{accessTokens}/de-authenticate
/answers
Returns all the undeleted answers in the system. The sorts accepted by this method operate on the follow fields of the answer object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of answers.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /answers
/answers/{ids}
Gets the set of answers identified by ids. This is meant for batch fetcing of questions. A useful trick to poll for updates is to sort by activity, with a minimum date of the last time you polled. {ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for answer_id on answer objects. The sorts accepted by this method operate on the follow fields of the answer object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of answers.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /answers/{ids}
/answers/{ids}/comments
Gets the comments on a set of answers. If you know that you have an answer id and need the comments, use this method. If you know you have a question id, use /questions/{id}/comments. If you are unsure, use /posts/{id}/comments. {ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for answer_id on answer objects. The sorts accepted by this method operate on the follow fields of the comment object: - creation - creation_date - votes - score creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /answers/{ids}/comments
/me/answers
Returns the answers owned by the user associated with the given access_token. This method returns a list of answers.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/answers
/me/questions/no-answers
Returns the questions owned by the user associated with the given access_token that have no answers. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/questions/no-answers
/me/questions/unanswered
Returns the questions owned by the user associated with the given access_token that are not considered answered. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/questions/unanswered
/me/tags/{tags}/top-answers
Returns the top 30 answers the user associated with the given access_token has posted in response to questions with the given tags. This method returns a list of answers.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tags | path | required | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/tags/{tags}/top-answers
/me/top-answer-tags
Returns the user identified by access_token's top 30 tags by answer score. This method returns a list of top tag objects.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/top-answer-tags
/questions/no-answers
Returns questions which have received no answers. Compare with /questions/unanswered which mearly returns questions that the sites consider insufficiently well answered. This method corresponds roughly with the this site tab. To constrain questions returned to those with a set of tags, use the tagged parameter with a semi-colon delimited list of tags. This is an and contraint, passing tagged=c;java will return only those questions with both tags. As such, passing more than 5 tags will always return zero results. The sorts accepted by this method operate on the follow fields of the question object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /questions/no-answers
/questions/unanswered
Returns questions the site considers to be unanswered. Note that just because a question has an answer, that does not mean it is considered answered. While the rules are subject to change, at this time a question must have at least one upvoted answer to be considered answered. To constrain questions returned to those with a set of tags, use the tagged parameter with a semi-colon delimited list of tags. This is an and contraint, passing tagged=c;java will return only those questions with both tags. As such, passing more than 5 tags will always return zero results. Compare with /questions/no-answers. This method corresponds roughly with the unanswered tab. The sorts accepted by this method operate on the follow fields of the question object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /questions/unanswered
/questions/{ids}/answers
Gets the answers to a set of questions identified in id. This method is most useful if you have a set of interesting questions, and you wish to obtain all of their answers at once or if you are polling for new or updates answers (in conjunction with sort=activity). {ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for question_id on question objects. The sorts accepted by this method operate on the follow fields of the answer object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of answers.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /questions/{ids}/answers
/tags/{tag}/top-answerers/{period}
Returns the top 30 answerers active in a single tag, of either all-time or the last 30 days. This is a view onto the data presented on the tag info page on the sites. This method returns a list of tag score objects.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tag | path | required | string | |
| period | path | required | string | |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /tags/{tag}/top-answerers/{period}
/me/associated
Returns all of a user's associated accounts, given an access_token for them. This method returns a list of network users.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
GET /me/associated
/badges
Returns all the badges in the system. Badge sorts are a tad complicated. For the purposes of sorting (and min/max) tag_based is considered to be greater than named. This means that you can get a list of all tag based badges by passing min=tag_based, and conversely all the named badges by passing max=named, with sort=type. For ranks, bronze is greater than silver which is greater than gold. Along with sort=rank, set max=gold for just gold badges, max=silver&min=silver for just silver, and min=bronze for just bronze. rank is the default sort. This method returns a list of badges.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| inname | query | optional | string | |
| order | query | optional | string | |
| max | query | optional | string | sort = rank => string sort = name => string sort = type => string |
| min | query | optional | string | sort = rank => string sort = name => string sort = type => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /badges
/badges/name
Gets all explicitly named badges in the system. A named badged stands in opposition to a tag-based badge. These are referred to as general badges on the sites themselves. For the rank sort, bronze is greater than silver which is greater than gold. Along with sort=rank, set max=gold for just gold badges, max=silver&min=silver for just silver, and min=bronze for just bronze. rank is the default sort. This method returns a list of badges.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| inname | query | optional | string | |
| order | query | optional | string | |
| max | query | optional | string | sort = rank => string sort = name => string |
| min | query | optional | string | sort = rank => string sort = name => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /badges/name
/badges/recipients
Returns recently awarded badges in the system. As these badges have been awarded, they will have the badge.user property set. This method returns a list of badges.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /badges/recipients
/badges/tags
Returns the badges that are awarded for participation in specific tags. For the rank sort, bronze is greater than silver which is greater than gold. Along with sort=rank, set max=gold for just gold badges, max=silver&min=silver for just silver, and min=bronze for just bronze. rank is the default sort. This method returns a list of badges.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| inname | query | optional | string | |
| order | query | optional | string | |
| max | query | optional | string | sort = rank => string sort = name => string |
| min | query | optional | string | sort = rank => string sort = name => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /badges/tags
/badges/{ids}
Gets the badges identified in id. Note that badge ids are not constant across sites, and thus should be looked up via the /badges method. A badge id on a single site is, however, guaranteed to be stable. Badge sorts are a tad complicated. For the purposes of sorting (and min/max) tag_based is considered to be greater than named. This means that you can get a list of all tag based badges by passing min=tag_based, and conversely all the named badges by passing max=named, with sort=type. For ranks, bronze is greater than silver which is greater than gold. Along with sort=rank, set max=gold for just gold badges, max=silver&min=silver for just silver, and min=bronze for just bronze. rank is the default sort. {ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for badge_id on badge objects. This method returns a list of badges.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = rank => string sort = name => string sort = type => string |
| min | query | optional | string | sort = rank => string sort = name => string sort = type => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /badges/{ids}
/badges/{ids}/recipients
Returns recently awarded badges in the system, constrained to a certain set of badges. As these badges have been awarded, they will have the badge.user property set. {ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for badge_id on badge objects. This method returns a list of badges.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /badges/{ids}/recipients
/me/badges
Returns the badges earned by the user associated with the given access_token. This method returns a list of badges.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = rank => string sort = name => string sort = type => string |
| min | query | optional | string | sort = rank => string sort = name => string sort = type => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/badges
/comments
Gets all the comments on the site. If you're filtering for interesting comments (by score, creation date, etc.) make use of the sort paramter with appropriate min and max values. If you're looking to query conversations between users, instead use the /users/{ids}/mentioned and /users/{ids}/comments/{toid} methods. The sorts accepted by this method operate on the follow fields of the comment object: - creation - creation_date - votes - score creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /comments
/comments/{ids}
Gets the comments identified in id. This method is most useful if you have a cache of comment ids obtained through other means (such as /questions/{id}/comments) but suspect the data may be stale. {ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for comment_id on comment objects. The sorts accepted by this method operate on the follow fields of the comment object: - creation - creation_date - votes - score creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /comments/{ids}
/me/comments
Returns the comments owned by the user associated with the given access_token. This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/comments
/me/comments/{toId}
Returns the comments owned by the user associated with the given access_token that are in reply to the user identified by {toId}. This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| toId | path | required | integer | |
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/comments/{toId}
/questions/{ids}/comments
Gets the comments on a question. If you know that you have an question id and need the comments, use this method. If you know you have a answer id, use /answers/{ids}/comments. If you are unsure, use /posts/{ids}/comments. {ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for question_id on question objects. The sorts accepted by this method operate on the follow fields of the comment object: - creation - creation_date - votes - score creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /questions/{ids}/comments
/me/suggested-edits
Returns the suggested edits the user identified by access_token has submitted. This method returns a list of suggested-edits.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = approval => date sort = rejection => date |
| min | query | optional | string | sort = creation => date sort = approval => date sort = rejection => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/suggested-edits
/suggested-edits
Returns all the suggested edits in the systems. This method returns a list of suggested-edits. The sorts accepted by this method operate on the follow fields of the suggested_edit object: - creation - creation_date - approval - approval_date Does not return unapproved suggested_edits - rejection - rejection_date Does not return unrejected suggested_edits creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = approval => date sort = rejection => date |
| min | query | optional | string | sort = creation => date sort = approval => date sort = rejection => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /suggested-edits
/suggested-edits/{ids}
Returns suggested edits identified in ids. {ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for suggested_edit_id on suggested_edit objects. The sorts accepted by this method operate on the follow fields of the suggested_edit object: - creation - creation_date - approval - approval_date Does not return unapproved suggested_edits - rejection - rejection_date Does not return unrejected suggested_edits creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of suggested-edits.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = approval => date sort = rejection => date |
| min | query | optional | string | sort = creation => date sort = approval => date sort = rejection => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /suggested-edits/{ids}
/errors
Returns the various error codes that can be produced by the API. This method is provided for discovery, documentation, and testing purposes, it is not expected many applications will consume it during normal operation. For testing purposes, look into the /errors/{id} method which simulates errors given a code. This method returns a list of errors.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
GET /errors
/errors/{id}
This method allows you to generate an error. This method is only intended for use when testing an application or library. Unlike other methods in the API, its contract is not frozen, and new error codes may be added at any time. This method results in an error, which will be expressed with a 400 HTTP status code and setting the error* properties on the wrapper object.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| id | path | required | integer |
GET /errors/{id}
/events
Returns a stream of events that have occurred on the site. The API considers the following "events": - posting a question - posting an answer - posting a comment - editing a post - creating a user Events are only accessible for 15 minutes after they occurred, and by default only events in the last 5 minutes are returned. You can specify the age of the oldest event returned by setting the since parameter. It is advised that developers batch events by ids and make as few subsequent requests to other methods as possible. This method returns a list of events.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
| since | query | optional | integer | Unix date. |
GET /events
/me/favorites
Returns the questions favorites 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 sort = creation => date sort = votes => number sort = added => date |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = added => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/favorites
/filters/create
Creates a new filter given a list of includes, excludes, a base filter, and whether or not this filter should be "unsafe". Filter "safety" is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. If no base filter is specified, the default filter is assumed. When building a filter from scratch, the none built-in filter is useful. When the size of the parameters being sent to this method grows to large, problems can occur. This method will accept POST requests to mitigate this. It is not expected that many applications will call this method at runtime, filters should be pre-calculated and "baked in" in the common cases. Furthermore, there are a number of built-in filters which cover common use cases. This method returns a single filter.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| base | query | optional | string | |
| exclude | query | optional | string | String list (semicolon delimited). |
| include | query | optional | string | String list (semicolon delimited). |
| unsafe | query | optional | boolean |
GET /filters/create
/filters/{filters}
Returns the fields included by the given filters, and the "safeness" of those filters. It is not expected that this method will be consumed by many applications at runtime, it is provided to aid in debugging. {filters} can contain up to 20 semicolon delimited filters. Filters are obtained via calls to /filters/create, or by using a built-in filter. This method returns a list of filters.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| filters | path | required | string | String list (semicolon delimited). |
GET /filters/{filters}
/info
Returns a collection of statistics about the site. Data to facilitate per-site customization, discover related sites, and aggregate statistics is all returned by this method. This data is cached very aggressively, by design. Query sparingly, ideally no more than once an hour. This method returns an info object.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /info
/tags
Returns the tags found on a site. The inname parameter lets a consumer filter down to tags that contain a certain substring. For example, inname=own would return both "download" and "owner" amongst others. This method returns a list of tags. The sorts accepted by this method operate on the follow fields of the tag object: - popular - count - activity - the creation_date of the last question asked with the tag - name - name popular is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| inname | query | optional | string | |
| order | query | optional | string | |
| max | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| min | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /tags
/me/mentioned
Returns the comments mentioning the user associated with the given access_token. This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/mentioned
/me/merges
Returns a record of merges that have occurred involving a user identified by an access_token. This method allows you to take now invalid account ids and find what account they've become, or take currently valid account ids and find which ids were equivalent in the past. This is most useful when confirming that an account_id is in fact "new" to an application. Account merges can happen for a wide range of reasons, applications should not make assumptions that merges have particular causes. Note that accounts are managed at a network level, users on a site may be merged due to an account level merge but there is no guarantee that a merge has an effect on any particular site. This method returns a list of account_merge.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
GET /me/merges
/inbox
Returns a user's inbox. This method requires an access_token, with a scope containing "read_inbox". This method returns a list of inbox items.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
GET /inbox
/inbox/unread
Returns the unread items in a user's inbox. This method requires an access_token, with a scope containing "read_inbox". This method returns a list of inbox items.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| since | query | optional | integer | Unix date. |
GET /inbox/unread
/me/inbox
Returns the user identified by access_token's inbox. This method requires an access_token, with a scope containing "read_inbox". This method returns a list of inbox items.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/inbox
/me/inbox/unread
Returns the unread items in the user identified by access_token's inbox. This method requires an access_token, with a scope containing "read_inbox". This method returns a list of inbox items.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
| since | query | optional | integer | Unix date. |
GET /me/inbox/unread
/me/notifications
Returns a user's notifications, given an access_token. This method requires an access_token, with a scope containing "read_inbox". This method returns a list of notifications.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/notifications
/me/notifications/unread
Returns a user's unread notifications, given an access_token. This method requires an access_token, with a scope containing "read_inbox". This method returns a list of notifications.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /me/notifications/unread
/notifications
Returns a user's notifications. This method requires an access_token, with a scope containing "read_inbox". This method returns a list of notifications.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
GET /notifications
/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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of posts.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of 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 sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - creation - creation_date - votes - score creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /posts/{ids}/revisions
/posts/{ids}/suggested-edits
Returns suggsted edits on the posts identified in ids. - creation - creation_date - approval - approval_date - rejection - rejection_date creation is the default sort. {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 sort = approval => date sort = rejection => date |
| min | query | optional | string | sort = creation => date sort = approval => date sort = rejection => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /posts/{ids}/suggested-edits
/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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - activity - last_activity_date - creation - creation_date - votes - score - relevance - matches the relevance tab on the site itself Does not accept min or max activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
| intitle | query | optional | string | |
| nottagged | query | optional | string | String list (semicolon delimited). |
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: - activity - last_activity_date - creation - creation_date - votes - score - relevance - order by "how similar" the questions are, most likely candidate first with a descending order Does not accept min or max activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
| nottagged | query | optional | string | String list (semicolon delimited). |
| title | query | optional | string |
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 sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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 sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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 sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - activity - last_activity_date - creation - creation_date - votes - score - hot - by the formula ordering the hot tab Does not accept min or max - week - by the formula ordering the week tab Does not accept min or max - month - by the formula ordering the month tab Does not accept min or max activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = hot => none sort = week => none sort = month => none sort = relevance => none |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = hot => none sort = week => none sort = month => none sort = relevance => none |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - activity - last_activity_date - creation - creation_date - votes - score - rank - a priority sort by site applies, subject to change at any time Does not accept min or max activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = rank => none |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = rank => none |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - activity - last_activity_date - creation - creation_date - votes - score - rank - a priority sort by site applies, subject to change at any time Does not accept min or max activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = rank => none |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = rank => none |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /revisions/{ids}
/search/advanced
Searches a site for any questions which fit the given criteria. Search criteria are expressed using the following parameters: - q - a free form text parameter, will match all question properties based on an undocumented algorithm. - accepted - true to return only questions with accepted answers, false to return only those without. Omit to elide constraint. - answers - the minimum number of answers returned questions must have. - body - text which must appear in returned questions' bodies. - closed - true to return only closed questions, false to return only open ones. Omit to elide constraint. - migrated - true to return only questions migrated away from a site, false to return only those not. Omit to elide constraint. - notice - true to return only questions with post notices, false to return only those without. Omit to elide constraint. - nottagged - a semicolon delimited list of tags, none of which will be present on returned questions. - tagged - a semicolon delimited list of tags, of which at least one will be present on all returned questions. - title - text which must appear in returned questions' titles. - user - the id of the user who must own the questions returned. - url - a url which must be contained in a post, may include a wildcard. - views - the minimum number of views returned questions must have. - wiki - true to return only community wiki questions, false to return only non-community wiki ones. Omit to elide constraint. 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: - activity - last_activity_date - creation - creation_date - votes - score - relevance - matches the relevance tab on the site itself Does not accept min or max activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tagged | query | optional | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
| 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 |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
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 sort = activity => date sort = name => string |
| min | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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 sort = creation => date sort = votes => number sort = hot => none sort = week => none sort = month => none sort = relevance => none |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = hot => none sort = week => none sort = month => none sort = relevance => none |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - popular - count - activity - the creation_date of the last question asked with the tag - name - name popular is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| inname | query | optional | string | |
| order | query | optional | string | |
| max | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| min | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - popular - count - activity - the creation_date of the last question asked with the tag - name - name popular is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| inname | query | optional | string | |
| order | query | optional | string | |
| max | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| min | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - creation - creation_date - applied - applied_count - activity - last_applied_date creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of tag_synonyms.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = applied => number sort = activity => date |
| min | query | optional | string | sort = creation => date sort = applied => number 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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - popular - count - activity - the creation_date of the last question asked with the tag - name - name popular is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| tags | path | required | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| min | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - creation - creation_date - applied - applied_count - activity - last_applied_date creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of 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 sort = applied => number sort = activity => date |
| min | query | optional | string | sort = creation => date sort = applied => number 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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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 sort = creation => date sort = name => string sort = modified => date |
| min | query | optional | string | sort = reputation => number sort = creation => date sort = name => string sort = modified => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - reputation - reputation - creation - creation_date - name - display_name - modified - last_modified_date reputation is the default sort. 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 sort = creation => date sort = name => string sort = modified => date |
| min | query | optional | string | sort = reputation => number sort = creation => date sort = name => string sort = modified => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - reputation - reputation - creation - creation_date - name - display_name - modified - last_modified_date reputation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of users.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = reputation => number sort = creation => date sort = name => string sort = modified => date |
| min | query | optional | string | sort = reputation => number sort = creation => date sort = name => string sort = modified => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - reputation - reputation - creation - creation_date - name - display_name - modified - last_modified_date reputation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of users.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| order | query | optional | string | |
| max | query | optional | string | sort = reputation => number sort = creation => date sort = name => string sort = modified => date |
| min | query | optional | string | sort = reputation => number sort = creation => date sort = name => string sort = modified => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - reputation - reputation - creation - creation_date - name - display_name - modified - last_modified_date reputation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of 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 sort = creation => date sort = name => string sort = modified => date |
| min | query | optional | string | sort = reputation => number sort = creation => date sort = name => string sort = modified => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of answers.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
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 sort = name => string sort = type => string sort = awarded => date |
| min | query | optional | string | sort = rank => string sort = name => string sort = type => string sort = awarded => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - creation - creation_date - votes - score creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of comments.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
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: - creation - creation_date - votes - score creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of comments.
| 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 sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/comments/{toid}
/users/{ids}/favorites
Get the questions that users in {ids} have favorited. This method is effectively a view onto a user's favorites tab. {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 question object: - activity - last_activity_date - creation - creation_date - votes - score - added - when the user favorited the question activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = added => date |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number sort = added => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/favorites
/users/{ids}/mentioned
Gets all the comments that the users in {ids} were mentioned in. Note, to count as a mention the comment must be considered to be "in reply to" a user. Most importantly, this means that a comment can only be in reply to a single user. {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: - creation - creation_date - votes - score 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 sort = votes => number |
| min | query | optional | string | sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/mentioned
/users/{ids}/merges
Returns a record of merges that have occurred involving the passed account ids. This method allows you to take now invalid account ids and find what account they've become, or take currently valid account ids and find which ids were equivalent in the past. This is most useful when confirming that an account_id is in fact "new" to an application. Account merges can happen for a wide range of reasons, applications should not make assumptions that merges have particular causes. Note that accounts are managed at a network level, users on a site may be merged due to an account level merge but there is no guarantee that a merge has an effect on any particular site. This method returns a list of account_merge.
| 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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
GET /users/{ids}/merges
/users/{ids}/questions
Gets the questions asked by the 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 question object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/questions
/users/{ids}/questions/featured
Gets the questions on which the users in {ids} have active bounties. {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 question object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/questions/featured
/users/{ids}/questions/no-answers
Gets the questions asked by the users in {ids} which have no answers. Questions returns by this method actually have zero undeleted answers. It is completely disjoint /users/{ids}/questions/unanswered and /users/{ids}/questions/unaccepted, which only return questions with at least one answer, subject to other contraints. {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 question object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/questions/no-answers
/users/{ids}/questions/unaccepted
Gets the questions asked by the users in {ids} which have at least one answer, but no accepted answer. Questions returned by this method have answers, but the owner has not opted to accept any of them. {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 question object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/questions/unaccepted
/users/{ids}/questions/unanswered
Gets the questions asked by the users in {ids} which the site consideres unanswered, while still having at least one answer posted. These rules are subject to change, but currently any question without at least one upvoted or accepted answer is considered unanswered. To get the set of questions that a user probably considers unanswered, the returned questions should be unioned with those returned by /users/{id}/questions/no-answers. These methods are distinct so that truly unanswered (that is, zero posted answers) questions can be easily separated from mearly poorly or inadequately answered ones. {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 question object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/questions/unanswered
/users/{ids}/reputation
Gets a subset of the reputation changes for users in {ids}. Reputation changes are intentionally scrubbed of some data to make it difficult to correlate votes on particular posts with user reputation changes. That being said, this method returns enough data for reasonable display of reputation trends. {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 reputation objects.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/reputation
/users/{ids}/reputation-history
Returns users' public reputation history. This method returns a list of reputation_history.
| 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). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/reputation-history
/users/{ids}/suggested-edits
Returns the suggested edits a users in {ids} have submitted. {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 suggested_edit object: - creation - creation_date - approval - approval_date Does not return unapproved suggested_edits - rejection - rejection_date Does not return unrejected suggested_edits creation is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of suggested-edits.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = creation => date sort = approval => date sort = rejection => date |
| min | query | optional | string | sort = creation => date sort = approval => date sort = rejection => date |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/suggested-edits
/users/{ids}/tags
Returns the tags the users identified in {ids} have been active in. This route corresponds roughly to user's stats tab, but does not include tag scores. A subset of tag scores are available (on a single user basis) in /users/{id}/top-answer-tags and /users/{id}/top-question-tags. {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 tag object: - popular - count - activity - the creation_date of the last question asked with the tag - name - name popular is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of tags.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| min | query | optional | string | sort = popular => number sort = activity => date sort = name => string |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/tags
/users/{ids}/timeline
Returns a subset of the actions the users in {ids} have taken on the site. This method returns users' posts, edits, and earned badges in the order they were accomplished. It is possible to filter to just a window of activity using the fromdate and todate parameters. {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 user timeline objects.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| ids | path | required | string | Number list (semicolon delimited). |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{ids}/timeline
/users/{id}/inbox
Returns a user's inbox. This method requires an access_token, with a scope containing "read_inbox". This method is effectively an alias for /inbox. It is provided for consumers who make strong assumptions about operating within the context of a single site rather than the Stack Exchange network as a whole. {id} can contain a single id, to find it programatically look for user_id on user or shallow_user objects. This method returns a list of inbox items.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| id | path | required | integer | |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{id}/inbox
/users/{id}/inbox/unread
Returns the unread items in a user's inbox. This method requires an access_token, with a scope containing "read_inbox". This method is effectively an alias for /inbox/unread. It is provided for consumers who make strong assumptions about operating within the context of a single site rather than the Stack Exchange network as a whole. {id} can contain a single id, to find it programatically look for user_id on user or shallow_user objects. This method returns a list of inbox items.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| id | path | required | integer | |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
| since | query | optional | integer | Unix date. |
GET /users/{id}/inbox/unread
/users/{id}/notifications
Returns a user's notifications. This method requires an access_token, with a scope containing "read_inbox". This method returns a list of notifications.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| id | path | required | integer | |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{id}/notifications
/users/{id}/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 |
|---|---|---|---|---|
| id | path | required | integer | |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{id}/notifications/unread
/users/{id}/privileges
Returns the privileges a user has. Applications are encouraged to calculate privileges themselves, without repeated queries to this method. A simple check against the results returned by /privileges and user.user_type would be sufficient. {id} can contain only a single, to find it programatically look for user_id on user or shallow_user objects. This method returns a list of privileges.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| id | path | required | integer | |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{id}/privileges
/users/{id}/reputation-history/full
Returns a 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 |
|---|---|---|---|---|
| id | path | required | integer | |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{id}/reputation-history/full
/users/{id}/tags/{tags}/top-answers
Returns the top 30 answers a user has posted in response to questions with the given tags. {id} can contain a single id, to find it programatically look for user_id on user or shallow_user objects. {tags} is limited to 5 tags, passing more will result in an error. The sorts accepted by this method operate on the follow fields of the answer object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of answers.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| id | path | required | integer | |
| tags | path | required | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{id}/tags/{tags}/top-answers
/users/{id}/tags/{tags}/top-questions
Returns the top 30 questions a user has asked with the given tags. {id} can contain a single id, to find it programatically look for user_id on user or shallow_user objects. {tags} is limited to 5 tags, passing more will result in an error. The sorts accepted by this method operate on the follow fields of the question object: - activity - last_activity_date - creation - creation_date - votes - score activity is the default sort. It is possible to create moderately complex queries using sort, min, max, fromdate, and todate. This method returns a list of questions.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| id | path | required | integer | |
| tags | path | required | string | String list (semicolon delimited). |
| order | query | optional | string | |
| max | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| min | query | optional | string | sort = activity => date sort = creation => date sort = votes => number |
| sort | query | optional | string | |
| fromdate | query | optional | integer | Unix date. |
| todate | query | optional | integer | Unix date. |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{id}/tags/{tags}/top-questions
/users/{id}/top-answer-tags
Returns a single user's top tags by answer score. This a subset of the data returned on a user's tags tab. {id} can contain a single id, to find it programatically look for user_id on user or shallow_user objects. This method returns a list of top_tag objects.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| id | path | required | integer | |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{id}/top-answer-tags
/users/{id}/top-question-tags
Returns a single user's top tags by question score. This a subset of the data returned on a user's tags tab. {id} can contain a single id, to find it programatically look for user_id on user or shallow_user objects. This method returns a list of top_tag objects.
| Name | In | Required | Type | Description |
|---|---|---|---|---|
| id | path | required | integer | |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{id}/top-question-tags
/users/{id}/write-permissions
Returns the write permissions a user has via the api. 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 |
|---|---|---|---|---|
| id | path | required | integer | |
| pagesize | query | optional | integer | |
| page | query | optional | integer | |
| filter | query | optional | string | #Discussion The Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users. An application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter. Filters are immutable and non-expiring. An application can safely "bake in" any filters that are created, it is not necessary (or advisable) to create filters at runtime. The motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family). #Safety Filters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections. Note that this does not mean that "safe" filter is mearly an "unsafe" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields). When using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the "safe" data is the only accessible data it will be returned even in "unsafe" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation. #Built In Filters The following filters are built in: default, each type documents which fields are returned under the default filter (for example, answers). withbody, which is default plus the *.body fields none, which is empty total, which includes just .total #Compatibility with V1.x For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters. |
| callback | query | optional | string | All API responses are JSON, we do support JSONP with the callback query parameter. |
| site | query | required | string | Each of these methods operates on a single site at a time, identified by the site parameter. This parameter can be the full domain name (ie. "stackoverflow.com"), or a short form identified by api_site_parameter on the site object. |
GET /users/{id}/write-permissions
access_tokens
{
"type": "array",
"items": {
"type": "object",
"properties": {
"scope": {
"type": "array",
"items": {}
},
"account_id": {
"type": "integer"
},
"access_token": {
"type": "string"
},
"expires_on_date": {
"type": "integer"
}
}
}
}
account_merge
{
"type": "array",
"items": {
"type": "object",
"properties": {
"merge_date": {
"type": "integer"
},
"new_account_id": {
"type": "integer"
},
"old_account_id": {
"type": "integer"
}
}
}
}
answers
{
"type": "array",
"items": {
"type": "object",
"properties": {
"body": {
"type": "string"
},
"link": {
"type": "string"
},
"tags": {
"type": "array",
"items": {}
},
"owner": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"score": {
"type": "integer"
},
"title": {
"type": "string"
},
"upvoted": {
"type": "boolean"
},
"accepted": {
"type": "boolean"
},
"can_flag": {
"type": "boolean"
},
"comments": {
"type": "array",
"items": {}
},
"answer_id": {
"type": "integer"
},
"downvoted": {
"type": "boolean"
},
"share_link": {
"type": "string"
},
"is_accepted": {
"type": "boolean"
},
"last_editor": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"locked_date": {
"type": "integer"
},
"question_id": {
"type": "integer"
},
"body_markdown": {
"type": "string"
},
"comment_count": {
"type": "integer"
},
"creation_date": {
"type": "integer"
},
"up_vote_count": {
"type": "integer"
},
"last_edit_date": {
"type": "integer"
},
"down_vote_count": {
"type": "integer"
},
"last_activity_date": {
"type": "integer"
},
"awarded_bounty_users": {
"type": "array",
"items": {}
},
"community_owned_date": {
"type": "integer"
},
"awarded_bounty_amount": {
"type": "integer"
}
}
}
}
badges
{
"type": "array",
"items": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"name": {
"type": "string"
},
"rank": {
"type": "string"
},
"user": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"badge_id": {
"type": "integer"
},
"badge_type": {
"type": "string"
},
"award_count": {
"type": "integer"
},
"description": {
"type": "string"
}
}
}
}
comments
{
"type": "array",
"items": {
"type": "object",
"properties": {
"body": {
"type": "string"
},
"link": {
"type": "string"
},
"owner": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"score": {
"type": "integer"
},
"edited": {
"type": "boolean"
},
"post_id": {
"type": "integer"
},
"upvoted": {
"type": "boolean"
},
"can_flag": {
"type": "boolean"
},
"post_type": {
"type": "string"
},
"comment_id": {
"type": "integer"
},
"body_markdown": {
"type": "string"
},
"creation_date": {
"type": "integer"
},
"reply_to_user": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
}
}
}
}
created_comment
{
"type": "object",
"properties": {
"body": {
"type": "string"
},
"link": {
"type": "string"
},
"owner": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"score": {
"type": "integer"
},
"edited": {
"type": "boolean"
},
"post_id": {
"type": "integer"
},
"upvoted": {
"type": "boolean"
},
"can_flag": {
"type": "boolean"
},
"post_type": {
"type": "string"
},
"comment_id": {
"type": "integer"
},
"body_markdown": {
"type": "string"
},
"creation_date": {
"type": "integer"
},
"reply_to_user": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
}
}
}
error
{
"type": "object",
"properties": {
"error_id": {
"type": "number"
},
"error_name": {
"type": "string"
},
"error_message": {
"type": "string"
}
}
}
errors
{
"type": "array",
"items": {
"type": "object",
"properties": {
"error_id": {
"type": "integer"
},
"error_name": {
"type": "string"
},
"description": {
"type": "string"
}
}
}
}
events
{
"type": "array",
"items": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"excerpt": {
"type": "string"
},
"event_type": {
"type": "string"
},
"creation_date": {
"type": "integer"
},
"the id of the object (answer, comment, question, or user) the event describes": {
"type": "integer"
}
}
}
}
filters
{
"type": "array",
"items": {
"type": "object",
"properties": {
"filter": {
"type": "string"
},
"filter_type": {
"type": "string"
},
"included_fields": {
"type": "array",
"items": {}
}
}
}
}
inbox_items
{
"type": "array",
"items": {
"type": "object",
"properties": {
"body": {
"type": "string"
},
"link": {
"type": "string"
},
"site": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"aliases": {
"type": "array",
"items": {}
},
"styling": {
"type": "object",
"properties": {
"link_color": {
"type": "string"
},
"tag_background_color": {
"type": "string"
},
"tag_foreground_color": {
"type": "string"
}
}
},
"audience": {
"type": "string"
},
"icon_url": {
"type": "string"
},
"logo_url": {
"type": "string"
},
"site_url": {
"type": "string"
},
"site_type": {
"type": "string"
},
"site_state": {
"type": "string"
},
"favicon_url": {
"type": "string"
},
"launch_date": {
"type": "integer"
},
"related_sites": {
"type": "array",
"items": {}
},
"open_beta_date": {
"type": "integer"
},
"twitter_account": {
"type": "string"
},
"closed_beta_date": {
"type": "integer"
},
"api_site_parameter": {
"type": "string"
},
"markdown_extensions": {
"type": "array",
"items": {}
},
"high_resolution_icon_url": {
"type": "string"
}
}
},
"title": {
"type": "string"
},
"answer_id": {
"type": "integer"
},
"is_unread": {
"type": "boolean"
},
"item_type": {
"type": "string"
},
"comment_id": {
"type": "integer"
},
"question_id": {
"type": "integer"
},
"creation_date": {
"type": "integer"
}
}
}
}
info_object
{
"type": "object",
"properties": {
"site": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"aliases": {
"type": "array",
"items": {}
},
"styling": {
"type": "object",
"properties": {
"link_color": {
"type": "string"
},
"tag_background_color": {
"type": "string"
},
"tag_foreground_color": {
"type": "string"
}
}
},
"audience": {
"type": "string"
},
"icon_url": {
"type": "string"
},
"logo_url": {
"type": "string"
},
"site_url": {
"type": "string"
},
"site_type": {
"type": "string"
},
"site_state": {
"type": "string"
},
"favicon_url": {
"type": "string"
},
"launch_date": {
"type": "integer"
},
"related_sites": {
"type": "array",
"items": {}
},
"open_beta_date": {
"type": "integer"
},
"twitter_account": {
"type": "string"
},
"closed_beta_date": {
"type": "integer"
},
"api_site_parameter": {
"type": "string"
},
"markdown_extensions": {
"type": "array",
"items": {}
},
"high_resolution_icon_url": {
"type": "string"
}
}
},
"total_users": {
"type": "integer"
},
"total_votes": {
"type": "integer"
},
"api_revision": {
"type": "string"
},
"total_badges": {
"type": "integer"
},
"total_answers": {
"type": "integer"
},
"total_accepted": {
"type": "integer"
},
"total_comments": {
"type": "integer"
},
"total_questions": {
"type": "integer"
},
"new_active_users": {
"type": "integer"
},
"total_unanswered": {
"type": "integer"
},
"badges_per_minute": {
"type": "number"
},
"answers_per_minute": {
"type": "number"
},
"questions_per_minute": {
"type": "number"
}
}
}
network_users
{
"type": "array",
"items": {
"type": "object",
"properties": {
"user_id": {
"type": "integer"
},
"site_url": {
"type": "string"
},
"site_name": {
"type": "string"
},
"user_type": {
"type": "string"
},
"account_id": {
"type": "integer"
},
"reputation": {
"type": "integer"
},
"top_answers": {
"type": "array",
"items": {}
},
"answer_count": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"creation_date": {
"type": "integer"
},
"top_questions": {
"type": "array",
"items": {}
},
"question_count": {
"type": "integer"
},
"last_access_date": {
"type": "integer"
}
}
}
}
notifications
{
"type": "array",
"items": {
"type": "object",
"properties": {
"body": {
"type": "string"
},
"site": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"aliases": {
"type": "array",
"items": {}
},
"styling": {
"type": "object",
"properties": {
"link_color": {
"type": "string"
},
"tag_background_color": {
"type": "string"
},
"tag_foreground_color": {
"type": "string"
}
}
},
"audience": {
"type": "string"
},
"icon_url": {
"type": "string"
},
"logo_url": {
"type": "string"
},
"site_url": {
"type": "string"
},
"site_type": {
"type": "string"
},
"site_state": {
"type": "string"
},
"favicon_url": {
"type": "string"
},
"launch_date": {
"type": "integer"
},
"related_sites": {
"type": "array",
"items": {}
},
"open_beta_date": {
"type": "integer"
},
"twitter_account": {
"type": "string"
},
"closed_beta_date": {
"type": "integer"
},
"api_site_parameter": {
"type": "string"
},
"markdown_extensions": {
"type": "array",
"items": {}
},
"high_resolution_icon_url": {
"type": "string"
}
}
},
"post_id": {
"type": "integer"
},
"is_unread": {
"type": "boolean"
},
"creation_date": {
"type": "integer"
},
"notification_type": {
"type": "string"
}
}
}
}
posts
{
"type": "array",
"items": {
"type": "object",
"properties": {
"body": {
"type": "string"
},
"link": {
"type": "string"
},
"owner": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"score": {
"type": "integer"
},
"title": {
"type": "string"
},
"post_id": {
"type": "integer"
},
"upvoted": {
"type": "boolean"
},
"comments": {
"type": "array",
"items": {}
},
"downvoted": {
"type": "boolean"
},
"post_type": {
"type": "string"
},
"share_link": {
"type": "string"
},
"last_editor": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"body_markdown": {
"type": "string"
},
"comment_count": {
"type": "integer"
},
"creation_date": {
"type": "integer"
},
"up_vote_count": {
"type": "integer"
},
"last_edit_date": {
"type": "integer"
},
"down_vote_count": {
"type": "integer"
},
"last_activity_date": {
"type": "integer"
}
}
}
}
privileges
{
"type": "array",
"items": {
"type": "object",
"properties": {
"reputation": {
"type": "integer"
},
"description": {
"type": "string"
},
"short_description": {
"type": "string"
}
}
}
}
question_timeline_events
{
"type": "array",
"items": {
"type": "object",
"properties": {
"user": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"owner": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"post_id": {
"type": "integer"
},
"comment_id": {
"type": "integer"
},
"question_id": {
"type": "integer"
},
"creation_date": {
"type": "integer"
},
"revision_guid": {
"type": "string"
},
"timeline_type": {
"type": "string"
},
"up_vote_count": {
"type": "integer"
},
"down_vote_count": {
"type": "integer"
}
}
}
}
questions
{
"type": "array",
"items": {
"type": "object",
"properties": {
"body": {
"type": "string"
},
"link": {
"type": "string"
},
"tags": {
"type": "array",
"items": {}
},
"owner": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"score": {
"type": "integer"
},
"title": {
"type": "string"
},
"notice": {
"type": "object",
"properties": {
"body": {
"type": "string"
},
"creation_date": {
"type": "integer"
},
"owner_user_id": {
"type": "integer"
}
}
},
"answers": {
"type": "array",
"items": {}
},
"upvoted": {
"type": "boolean"
},
"can_flag": {
"type": "boolean"
},
"comments": {
"type": "array",
"items": {}
},
"can_close": {
"type": "boolean"
},
"downvoted": {
"type": "boolean"
},
"favorited": {
"type": "boolean"
},
"share_link": {
"type": "string"
},
"view_count": {
"type": "integer"
},
"bounty_user": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"closed_date": {
"type": "integer"
},
"is_answered": {
"type": "boolean"
},
"last_editor": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"locked_date": {
"type": "integer"
},
"migrated_to": {
"type": "object",
"properties": {
"on_date": {
"type": "integer"
},
"other_site": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"aliases": {
"type": "array",
"items": {}
},
"styling": {
"type": "object",
"properties": {
"link_color": {
"type": "string"
},
"tag_background_color": {
"type": "string"
},
"tag_foreground_color": {
"type": "string"
}
}
},
"audience": {
"type": "string"
},
"icon_url": {
"type": "string"
},
"logo_url": {
"type": "string"
},
"site_url": {
"type": "string"
},
"site_type": {
"type": "string"
},
"site_state": {
"type": "string"
},
"favicon_url": {
"type": "string"
},
"launch_date": {
"type": "integer"
},
"related_sites": {
"type": "array",
"items": {}
},
"open_beta_date": {
"type": "integer"
},
"twitter_account": {
"type": "string"
},
"closed_beta_date": {
"type": "integer"
},
"api_site_parameter": {
"type": "string"
},
"markdown_extensions": {
"type": "array",
"items": {}
},
"high_resolution_icon_url": {
"type": "string"
}
}
},
"question_id": {
"type": "integer"
}
}
},
"question_id": {
"type": "integer"
},
"answer_count": {
"type": "integer"
},
"body_markdown": {
"type": "string"
},
"bounty_amount": {
"type": "integer"
},
"closed_reason": {
"type": "string"
},
"comment_count": {
"type": "integer"
},
"creation_date": {
"type": "integer"
},
"migrated_from": {
"type": "object",
"properties": {
"on_date": {
"type": "integer"
},
"other_site": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"aliases": {
"type": "array",
"items": {}
},
"styling": {
"type": "object",
"properties": {
"link_color": {
"type": "string"
},
"tag_background_color": {
"type": "string"
},
"tag_foreground_color": {
"type": "string"
}
}
},
"audience": {
"type": "string"
},
"icon_url": {
"type": "string"
},
"logo_url": {
"type": "string"
},
"site_url": {
"type": "string"
},
"site_type": {
"type": "string"
},
"site_state": {
"type": "string"
},
"favicon_url": {
"type": "string"
},
"launch_date": {
"type": "integer"
},
"related_sites": {
"type": "array",
"items": {}
},
"open_beta_date": {
"type": "integer"
},
"twitter_account": {
"type": "string"
},
"closed_beta_date": {
"type": "integer"
},
"api_site_parameter": {
"type": "string"
},
"markdown_extensions": {
"type": "array",
"items": {}
},
"high_resolution_icon_url": {
"type": "string"
}
}
},
"question_id": {
"type": "integer"
}
}
},
"up_vote_count": {
"type": "integer"
},
"closed_details": {
"type": "object",
"properties": {
"reason": {
"type": "string"
},
"on_hold": {
"type": "boolean"
},
"by_users": {
"type": "array",
"items": {}
},
"description": {
"type": "string"
},
"original_questions": {
"type": "array",
"items": {}
}
}
},
"favorite_count": {
"type": "integer"
},
"last_edit_date": {
"type": "integer"
},
"protected_date": {
"type": "integer"
},
"down_vote_count": {
"type": "integer"
},
"close_vote_count": {
"type": "integer"
},
"delete_vote_count": {
"type": "integer"
},
"reopen_vote_count": {
"type": "integer"
},
"accepted_answer_id": {
"type": "integer"
},
"bounty_closes_date": {
"type": "integer"
},
"last_activity_date": {
"type": "integer"
},
"community_owned_date": {
"type": "integer"
}
}
}
}
reputation_changes
{
"type": "array",
"items": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"title": {
"type": "string"
},
"on_date": {
"type": "integer"
},
"post_id": {
"type": "integer"
},
"user_id": {
"type": "integer"
},
"post_type": {
"type": "string"
},
"vote_type": {
"type": "string"
},
"reputation_change": {
"type": "integer"
}
}
}
}
reputation_history
{
"type": "array",
"items": {
"type": "object",
"properties": {
"post_id": {
"type": "integer"
},
"user_id": {
"type": "integer"
},
"creation_date": {
"type": "integer"
},
"reputation_change": {
"type": "integer"
},
"reputation_history_type": {
"type": "string"
}
}
}
}
reputation_objects
{
"type": "array",
"items": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"title": {
"type": "string"
},
"on_date": {
"type": "integer"
},
"post_id": {
"type": "integer"
},
"user_id": {
"type": "integer"
},
"post_type": {
"type": "string"
},
"vote_type": {
"type": "string"
},
"reputation_change": {
"type": "integer"
}
}
}
}
revisions
{
"type": "array",
"items": {
"type": "object",
"properties": {
"body": {
"type": "string"
},
"tags": {
"type": "array",
"items": {}
},
"user": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"title": {
"type": "string"
},
"comment": {
"type": "string"
},
"post_id": {
"type": "integer"
},
"last_body": {
"type": "string"
},
"last_tags": {
"type": "array",
"items": {}
},
"post_type": {
"type": "string"
},
"last_title": {
"type": "string"
},
"is_rollback": {
"type": "boolean"
},
"creation_date": {
"type": "integer"
},
"revision_guid": {
"type": "string"
},
"revision_type": {
"type": "string"
},
"revision_number": {
"type": "integer"
},
"set_community_wiki": {
"type": "boolean"
}
}
}
}
single_filter
{
"type": "object",
"properties": {
"filter": {
"type": "string"
},
"filter_type": {
"type": "string"
},
"included_fields": {
"type": "array",
"items": {}
}
}
}
sites
{
"type": "array",
"items": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"aliases": {
"type": "array",
"items": {}
},
"styling": {
"type": "object",
"properties": {
"link_color": {
"type": "string"
},
"tag_background_color": {
"type": "string"
},
"tag_foreground_color": {
"type": "string"
}
}
},
"audience": {
"type": "string"
},
"icon_url": {
"type": "string"
},
"logo_url": {
"type": "string"
},
"site_url": {
"type": "string"
},
"site_type": {
"type": "string"
},
"site_state": {
"type": "string"
},
"favicon_url": {
"type": "string"
},
"launch_date": {
"type": "integer"
},
"related_sites": {
"type": "array",
"items": {}
},
"open_beta_date": {
"type": "integer"
},
"twitter_account": {
"type": "string"
},
"closed_beta_date": {
"type": "integer"
},
"api_site_parameter": {
"type": "string"
},
"markdown_extensions": {
"type": "array",
"items": {}
},
"high_resolution_icon_url": {
"type": "string"
}
}
}
}
suggested-edits
{
"type": "array",
"items": {
"type": "object",
"properties": {
"body": {
"type": "string"
},
"tags": {
"type": "array",
"items": {}
},
"title": {
"type": "string"
},
"comment": {
"type": "string"
},
"post_id": {
"type": "integer"
},
"post_type": {
"type": "string"
},
"approval_date": {
"type": "integer"
},
"creation_date": {
"type": "integer"
},
"proposing_user": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"rejection_date": {
"type": "integer"
},
"suggested_edit_id": {
"type": "integer"
}
}
}
}
tag_score_objects
{
"type": "array",
"items": {
"type": "object",
"properties": {
"user": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"score": {
"type": "integer"
},
"post_count": {
"type": "integer"
}
}
}
}
tag_synonyms
{
"type": "array",
"items": {
"type": "object",
"properties": {
"to_tag": {
"type": "string"
},
"from_tag": {
"type": "string"
},
"applied_count": {
"type": "integer"
},
"creation_date": {
"type": "integer"
},
"last_applied_date": {
"type": "integer"
}
}
}
}
tag_wikis
{
"type": "array",
"items": {
"type": "object",
"properties": {
"body": {
"type": "string"
},
"excerpt": {
"type": "string"
},
"tag_name": {
"type": "string"
},
"last_body_editor": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"body_last_edit_date": {
"type": "integer"
},
"last_excerpt_editor": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"user_type": {
"type": "string"
},
"reputation": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"profile_image": {
"type": "string"
}
}
},
"excerpt_last_edit_date": {
"type": "integer"
}
}
}
}
tags
{
"type": "array",
"items": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"count": {
"type": "integer"
},
"user_id": {
"type": "integer"
},
"synonyms": {
"type": "array",
"items": {}
},
"is_required": {
"type": "boolean"
},
"has_synonyms": {
"type": "boolean"
},
"is_moderator_only": {
"type": "boolean"
},
"last_activity_date": {
"type": "integer"
}
}
}
}
top_tag_objects
{
"type": "array",
"items": {
"type": "object",
"properties": {
"user_id": {
"type": "integer"
},
"tag_name": {
"type": "string"
},
"answer_count": {
"type": "integer"
},
"answer_score": {
"type": "integer"
},
"question_count": {
"type": "integer"
},
"question_score": {
"type": "integer"
}
}
}
}
user
{
"type": "object",
"properties": {
"age": {
"type": "integer"
},
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"about_me": {
"type": "string"
},
"location": {
"type": "string"
},
"user_type": {
"type": "string"
},
"account_id": {
"type": "integer"
},
"reputation": {
"type": "integer"
},
"view_count": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"is_employee": {
"type": "boolean"
},
"website_url": {
"type": "string"
},
"answer_count": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"creation_date": {
"type": "integer"
},
"profile_image": {
"type": "string"
},
"up_vote_count": {
"type": "integer"
},
"question_count": {
"type": "integer"
},
"down_vote_count": {
"type": "integer"
},
"last_access_date": {
"type": "integer"
},
"last_modified_date": {
"type": "integer"
},
"timed_penalty_date": {
"type": "integer"
},
"reputation_change_day": {
"type": "integer"
},
"reputation_change_week": {
"type": "integer"
},
"reputation_change_year": {
"type": "integer"
},
"reputation_change_month": {
"type": "integer"
},
"reputation_change_quarter": {
"type": "integer"
}
}
}
user_timeline_objects
{
"type": "array",
"items": {
"type": "object",
"properties": {
"link": {
"type": "string"
},
"title": {
"type": "string"
},
"detail": {
"type": "string"
},
"post_id": {
"type": "integer"
},
"user_id": {
"type": "integer"
},
"badge_id": {
"type": "integer"
},
"post_type": {
"type": "string"
},
"comment_id": {
"type": "integer"
},
"creation_date": {
"type": "integer"
},
"timeline_type": {
"type": "string"
},
"suggested_edit_id": {
"type": "integer"
}
}
}
}
users
{
"type": "array",
"items": {
"type": "object",
"properties": {
"age": {
"type": "integer"
},
"link": {
"type": "string"
},
"user_id": {
"type": "integer"
},
"about_me": {
"type": "string"
},
"location": {
"type": "string"
},
"user_type": {
"type": "string"
},
"account_id": {
"type": "integer"
},
"reputation": {
"type": "integer"
},
"view_count": {
"type": "integer"
},
"accept_rate": {
"type": "integer"
},
"is_employee": {
"type": "boolean"
},
"website_url": {
"type": "string"
},
"answer_count": {
"type": "integer"
},
"badge_counts": {
"type": "object",
"properties": {
"gold": {
"type": "integer"
},
"bronze": {
"type": "integer"
},
"silver": {
"type": "integer"
}
}
},
"display_name": {
"type": "string"
},
"creation_date": {
"type": "integer"
},
"profile_image": {
"type": "string"
},
"up_vote_count": {
"type": "integer"
},
"question_count": {
"type": "integer"
},
"down_vote_count": {
"type": "integer"
},
"last_access_date": {
"type": "integer"
},
"last_modified_date": {
"type": "integer"
},
"timed_penalty_date": {
"type": "integer"
},
"reputation_change_day": {
"type": "integer"
},
"reputation_change_week": {
"type": "integer"
},
"reputation_change_year": {
"type": "integer"
},
"reputation_change_month": {
"type": "integer"
},
"reputation_change_quarter": {
"type": "integer"
}
}
}
}
write_permissions
{
"type": "array",
"items": {
"type": "object",
"properties": {
"can_add": {
"type": "boolean"
},
"user_id": {
"type": "integer"
},
"can_edit": {
"type": "boolean"
},
"can_delete": {
"type": "boolean"
},
"object_type": {
"type": "string"
},
"max_daily_actions": {
"type": "integer"
},
"min_seconds_between_actions": {
"type": "integer"
}
}
}
}