openapi: 3.0.0 info: description: > Stack Exchange is a network of 130+ Q&A communities including Stack Overflow. title: StackExchange version: "2.0" externalDocs: url: https://api.stackexchange.com/ paths: "/access-tokens/{accessTokens}": get: description: > 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. parameters: - description: String list (semicolon delimited). in: path name: accessTokens required: true schema: type: string - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/access_tokens" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/access-tokens/{accessTokens}/invalidate": get: description: > 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. parameters: - description: String list (semicolon delimited). in: path name: accessTokens required: true schema: type: string - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/access_tokens" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /answers: get: description: > 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. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/answers" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/answers/{ids}": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/answers" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/answers/{ids}/comments": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/apps/{accessTokens}/de-authenticate": get: description: > 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. parameters: - description: String list (semicolon delimited). in: path name: accessTokens required: true schema: type: string - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/access_tokens" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /badges: get: description: > 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. parameters: - in: query name: inname schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = rank => string sort = name => string sort = type => string in: query name: max schema: type: string - description: | sort = rank => string sort = name => string sort = type => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - rank - name - type - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/badges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /badges/name: get: description: > 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. parameters: - in: query name: inname schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = rank => string sort = name => string in: query name: max schema: type: string - description: | sort = rank => string sort = name => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - rank - name - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/badges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /badges/recipients: get: description: > 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. parameters: - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/badges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /badges/tags: get: description: > 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. parameters: - in: query name: inname schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = rank => string sort = name => string in: query name: max schema: type: string - description: | sort = rank => string sort = name => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - rank - name - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/badges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/badges/{ids}": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = rank => string sort = name => string sort = type => string in: query name: max schema: type: string - description: | sort = rank => string sort = name => string sort = type => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - rank - name - type - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/badges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/badges/{ids}/recipients": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/badges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /comments: get: description: > 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. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/comments/{ids}": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/comments/{id}/delete": post: description: | Deletes a comment. Use an access_token with write_access to delete a comment. In practice, this method will never return an object. parameters: - in: path name: id required: true schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string - in: query name: preview schema: type: boolean responses: "200": description: OK "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/comments/{id}/edit": post: description: | Edit an existing comment. Use an access_token with write_access to edit an existing comment. This method return the created comment. parameters: - in: path name: id required: true schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string - in: query name: body schema: type: string - in: query name: preview schema: type: boolean responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/created_comment" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /errors: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/errors" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/errors/{id}": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/error" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /events: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string - description: Unix date. in: query name: since schema: type: integer responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/events" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /filters/create: get: description: > 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. parameters: - in: query name: base schema: type: string - description: String list (semicolon delimited). in: query name: exclude schema: type: string - description: String list (semicolon delimited). in: query name: include schema: type: string - in: query name: unsafe schema: type: boolean responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/single_filter" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/filters/{filters}": get: description: > 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. parameters: - description: String list (semicolon delimited). in: path name: filters required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/filters" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /inbox: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/inbox_items" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /inbox/unread: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: Unix date. in: query name: since schema: type: integer responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/inbox_items" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /info: get: description: > 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. parameters: - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/info_object" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me: get: description: | Returns the user associated with the passed access_token. This method returns a user. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = reputation => number sort = creation => date sort = name => string sort = modified => date in: query name: max schema: type: string - description: | sort = reputation => number sort = creation => date sort = name => string sort = modified => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - reputation - creation - name - modified - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/user" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/answers: get: description: > Returns the answers owned by the user associated with the given access_token. This method returns a list of answers. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/answers" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/associated: get: description: > Returns all of a user's associated accounts, given an access_token for them. This method returns a list of network users. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/network_users" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/badges: get: description: > Returns the badges earned by the user associated with the given access_token. This method returns a list of badges. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = rank => string sort = name => string sort = type => string in: query name: max schema: type: string - description: | sort = rank => string sort = name => string sort = type => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - rank - name - type - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/badges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/comments: get: description: > Returns the comments owned by the user associated with the given access_token. This method returns a list of comments. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/me/comments/{toId}": get: description: > 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. parameters: - in: path name: toId required: true schema: type: integer - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/favorites: get: description: > Returns the questions favorites by the user associated with the given access_token. This method returns a list of questions. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number sort = added => date in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number sort = added => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - added - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/inbox: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/inbox_items" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/inbox/unread: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string - description: Unix date. in: query name: since schema: type: integer responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/inbox_items" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/mentioned: get: description: > Returns the comments mentioning the user associated with the given access_token. This method returns a list of comments. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/merges: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/account_merge" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/notifications: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/notifications" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/notifications/unread: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/notifications" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/privileges: get: description: | Returns the privileges the user identified by access_token has. This method returns a list of privileges. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/privileges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/questions: get: description: > Returns the questions owned by the user associated with the given access_token. This method returns a list of questions. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/questions/featured: get: description: > Returns the questions that have active bounties offered by the user associated with the given access_token. This method returns a list of questions. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/questions/no-answers: get: description: > Returns the questions owned by the user associated with the given access_token that have no answers. This method returns a list of questions. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/questions/unaccepted: get: description: > 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. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/questions/unanswered: get: description: > 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. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/reputation: get: description: > Returns the reputation changed for the user associated with the given access_token. This method returns a list of reputation changes. parameters: - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/reputation_changes" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/reputation-history: get: description: | Returns user's public reputation history. This method returns a list of reputation_history. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/reputation_history" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/reputation-history/full: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/reputation_history" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/suggested-edits: get: description: > Returns the suggested edits the user identified by access_token has submitted. This method returns a list of suggested-edits. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = approval => date sort = rejection => date in: query name: max schema: type: string - description: | sort = creation => date sort = approval => date sort = rejection => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - approval - rejection - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/suggested-edits" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/tags: get: description: > Returns the tags the user identified by the access_token passed is active in. This method returns a list of tags. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = popular => number sort = activity => date sort = name => string in: query name: max schema: type: string - description: | sort = popular => number sort = activity => date sort = name => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - popular - activity - name - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tags" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/me/tags/{tags}/top-answers": get: description: > 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. parameters: - description: String list (semicolon delimited). in: path name: tags required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/answers" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/me/tags/{tags}/top-questions": get: description: > 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. parameters: - description: String list (semicolon delimited). in: path name: tags required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number sort = hot => none sort = week => none sort = month => none sort = relevance => none in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number sort = hot => none sort = week => none sort = month => none sort = relevance => none in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - hot - week - month - relevance - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/timeline: get: description: > 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. parameters: - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/user_timeline_objects" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/top-answer-tags: get: description: > Returns the user identified by access_token's top 30 tags by answer score. This method returns a list of top tag objects. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/top_tag_objects" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/top-question-tags: get: description: > Returns the user identified by access_token's top 30 tags by question score. This method returns a list of top tag objects. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/top_tag_objects" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /me/write-permissions: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/write_permissions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /notifications: get: description: > Returns a user's notifications. This method requires an access_token, with a scope containing "read_inbox". This method returns a list of notifications. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/notifications" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /notifications/unread: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/notifications" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /posts: get: description: > 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. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/posts" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/posts/{ids}": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/posts" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/posts/{ids}/comments": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/posts/{ids}/revisions": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/revisions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/posts/{ids}/suggested-edits": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = approval => date sort = rejection => date in: query name: max schema: type: string - description: | sort = creation => date sort = approval => date sort = rejection => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - approval - rejection - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/suggested-edits" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/posts/{id}/comments/add": post: description: | Create a new comment. Use an access_token with write_access to create a new comment on a post. This method returns the created comment. parameters: - in: path name: id required: true schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string - in: query name: body schema: type: string - in: query name: preview schema: type: boolean responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/created_comment" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /privileges: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/privileges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /questions: get: description: > 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. parameters: - description: String list (semicolon delimited). in: query name: tagged schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number sort = hot => none sort = week => none sort = month => none sort = relevance => none in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number sort = hot => none sort = week => none sort = month => none sort = relevance => none in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - hot - week - month - relevance - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /questions/featured: get: description: > 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. parameters: - description: String list (semicolon delimited). in: query name: tagged schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /questions/no-answers: get: description: > 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. parameters: - description: String list (semicolon delimited). in: query name: tagged schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /questions/unanswered: get: description: > 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. parameters: - description: String list (semicolon delimited). in: query name: tagged schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/questions/{ids}": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/questions/{ids}/answers": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/answers" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/questions/{ids}/comments": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/questions/{ids}/linked": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number sort = rank => none in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number sort = rank => none in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - rank - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/questions/{ids}/related": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number sort = rank => none in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number sort = rank => none in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - rank - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/questions/{ids}/timeline": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/question_timeline_events" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/revisions/{ids}": get: description: > 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. parameters: - description: Guid list (semicolon delimited). in: path name: ids required: true schema: type: string - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/revisions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /search: get: description: > 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. parameters: - description: String list (semicolon delimited). in: query name: tagged schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - relevance - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string - in: query name: intitle schema: type: string - description: String list (semicolon delimited). in: query name: nottagged schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /search/advanced: get: description: > 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. parameters: - description: String list (semicolon delimited). in: query name: tagged schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - relevance - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string - in: query name: accepted schema: type: string enum: - true - false - in: query name: answers schema: type: integer - in: query name: body schema: type: string - in: query name: closed schema: type: string enum: - true - false - in: query name: migrated schema: type: string enum: - true - false - in: query name: notice schema: type: string enum: - true - false - description: String list (semicolon delimited). in: query name: nottagged schema: type: string - in: query name: q schema: type: string - in: query name: title schema: type: string - in: query name: url schema: type: string - in: query name: user schema: type: integer - in: query name: views schema: type: integer - in: query name: wiki schema: type: string enum: - true - false responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /similar: get: description: > 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. parameters: - description: String list (semicolon delimited). in: query name: tagged schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number sort = relevance => none in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - relevance - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string - description: String list (semicolon delimited). in: query name: nottagged schema: type: string - in: query name: title schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /sites: get: description: > 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. parameters: - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/sites" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /suggested-edits: get: description: > 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. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = approval => date sort = rejection => date in: query name: max schema: type: string - description: | sort = creation => date sort = approval => date sort = rejection => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - approval - rejection - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/suggested-edits" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/suggested-edits/{ids}": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = approval => date sort = rejection => date in: query name: max schema: type: string - description: | sort = creation => date sort = approval => date sort = rejection => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - approval - rejection - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/suggested-edits" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /tags: get: description: > 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. parameters: - in: query name: inname schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = popular => number sort = activity => date sort = name => string in: query name: max schema: type: string - description: | sort = popular => number sort = activity => date sort = name => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - popular - activity - name - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tags" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /tags/moderator-only: get: description: > 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. parameters: - in: query name: inname schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = popular => number sort = activity => date sort = name => string in: query name: max schema: type: string - description: | sort = popular => number sort = activity => date sort = name => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - popular - activity - name - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tags" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /tags/required: get: description: > 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. parameters: - in: query name: inname schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = popular => number sort = activity => date sort = name => string in: query name: max schema: type: string - description: | sort = popular => number sort = activity => date sort = name => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - popular - activity - name - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tags" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /tags/synonyms: get: description: > 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. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = applied => number sort = activity => date in: query name: max schema: type: string - description: | sort = creation => date sort = applied => number sort = activity => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - applied - activity - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tag_synonyms" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/tags/{tags}/faq": get: description: > 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. parameters: - description: String list (semicolon delimited). in: path name: tags required: true schema: type: string - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/tags/{tags}/info": get: description: > 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. parameters: - description: String list (semicolon delimited). in: path name: tags required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = popular => number sort = activity => date sort = name => string in: query name: max schema: type: string - description: | sort = popular => number sort = activity => date sort = name => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - popular - activity - name - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tags" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/tags/{tags}/related": get: description: > 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. parameters: - description: String list (semicolon delimited). in: path name: tags required: true schema: type: string - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tags" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/tags/{tags}/synonyms": get: description: > 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. parameters: - description: String list (semicolon delimited). in: path name: tags required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = applied => number sort = activity => date in: query name: max schema: type: string - description: | sort = creation => date sort = applied => number sort = activity => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - applied - activity - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tag_synonyms" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/tags/{tags}/wikis": get: description: | 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. parameters: - description: String list (semicolon delimited). in: path name: tags required: true schema: type: string - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tag_wikis" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/tags/{tag}/top-answerers/{period}": get: description: > 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. parameters: - in: path name: tag required: true schema: type: string - in: path name: period required: true schema: type: string enum: - all_time - month - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tag_score_objects" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/tags/{tag}/top-askers/{period}": get: description: > 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. parameters: - in: path name: tag required: true schema: type: string - in: path name: period required: true schema: type: string enum: - all_time - month - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tag_score_objects" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /users: get: description: > 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". parameters: - in: query name: inname schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = reputation => number sort = creation => date sort = name => string sort = modified => date in: query name: max schema: type: string - description: | sort = reputation => number sort = creation => date sort = name => string sort = modified => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - reputation - creation - name - modified - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/users" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /users/moderators: get: description: > 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. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = reputation => number sort = creation => date sort = name => string sort = modified => date in: query name: max schema: type: string - description: | sort = reputation => number sort = creation => date sort = name => string sort = modified => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - reputation - creation - name - modified - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/users" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. /users/moderators/elected: get: description: > 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. parameters: - in: query name: order schema: type: string enum: - desc - asc - description: | sort = reputation => number sort = creation => date sort = name => string sort = modified => date in: query name: max schema: type: string - description: | sort = reputation => number sort = creation => date sort = name => string sort = modified => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - reputation - creation - name - modified - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/users" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = reputation => number sort = creation => date sort = name => string sort = modified => date in: query name: max schema: type: string - description: | sort = reputation => number sort = creation => date sort = name => string sort = modified => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - reputation - creation - name - modified - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/users" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/answers": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/answers" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/associated": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/network_users" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/badges": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = rank => string sort = name => string sort = type => string sort = awarded => date in: query name: max schema: type: string - description: | sort = rank => string sort = name => string sort = type => string sort = awarded => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - rank - name - type - awarded - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/badges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/comments": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/comments/{toid}": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: path name: toid required: true schema: type: integer - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/favorites": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number sort = added => date in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number sort = added => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - added - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/mentioned": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/comments" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/merges": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/account_merge" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/questions": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/questions/featured": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/questions/no-answers": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/questions/unaccepted": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/questions/unanswered": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/reputation": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/reputation_changes" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/reputation-history": get: description: | Returns users' public reputation history. This method returns a list of reputation_history. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/reputation_history" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/suggested-edits": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = creation => date sort = approval => date sort = rejection => date in: query name: max schema: type: string - description: | sort = creation => date sort = approval => date sort = rejection => date in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - creation - approval - rejection - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/suggested-edits" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/tags": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = popular => number sort = activity => date sort = name => string in: query name: max schema: type: string - description: | sort = popular => number sort = activity => date sort = name => string in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - popular - activity - name - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/tags" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{ids}/timeline": get: description: > 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. parameters: - description: Number list (semicolon delimited). in: path name: ids required: true schema: type: string - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/user_timeline_objects" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/inbox": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/inbox_items" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/inbox/unread": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string - description: Unix date. in: query name: since schema: type: integer responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/inbox_items" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/notifications": get: description: > Returns a user's notifications. This method requires an access_token, with a scope containing "read_inbox". This method returns a list of notifications. parameters: - in: path name: id required: true schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/notifications" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/notifications/unread": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/notifications" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/privileges": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/privileges" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/reputation-history/full": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/reputation_history" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/tags/{tags}/top-answers": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer - description: String list (semicolon delimited). in: path name: tags required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/answers" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/tags/{tags}/top-questions": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer - description: String list (semicolon delimited). in: path name: tags required: true schema: type: string - in: query name: order schema: type: string enum: - desc - asc - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: max schema: type: string - description: | sort = activity => date sort = creation => date sort = votes => number in: query name: min schema: type: string - in: query name: sort schema: type: string enum: - activity - creation - votes - description: Unix date. in: query name: fromdate schema: type: integer - description: Unix date. in: query name: todate schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/questions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/top-answer-tags": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/top_tag_objects" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/top-question-tags": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/top_tag_objects" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. "/users/{id}/write-permissions": get: description: > 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. parameters: - in: path name: id required: true schema: type: integer - in: query name: pagesize schema: type: integer - in: query name: page schema: type: integer - description: > #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. in: query name: filter schema: type: string - description: > All API responses are JSON, we do support JSONP with the callback query parameter. in: query name: callback schema: type: string - description: > 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. in: query name: site required: true schema: type: string responses: "200": description: OK content: "*/*": schema: $ref: "#/components/schemas/write_permissions" "400": description: > bad_parameter – 400 An invalid parameter was passed, this includes even "high level" parameters like key or site. "401": description: > access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one. "402": description: > invalid_access_token – 402 An invalid access token was passed to a method. "403": description: > access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions. "404": description: > no_method – 404 An attempt was made to call a method that does not exist. Note, calling methods that expect numeric ids (like /users/{ids}) with non-numeric ids can also result in this error. "405": description: > key_required – 405 A method was called in a manner that requires an application key (generally, with an access token), but no key was passed. "406": description: > access_token_compromised – 406 An access token is no longer believed to be secure, normally because it was used on a non-HTTPS call. The access token will be invalidated if this error is returned. "500": description: > internal_error – 500 An unexpected error occurred in the API. It has been logged, and Stack Exchange developers have been notified. You should report these errors on Stack Apps if you want to be notified when they're fixed. "502": description: > throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated. "503": description: > temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked. servers: - url: https://api.stackexchange.com/2.0 components: securitySchemes: oauth_2_0: description: > The Stack Exchange API offers user authentication via OAuth 2.0, specifically templated after Facebook's implementation. There are two flows, an explicit grant for server side applications and an implicit one for pure browser based ones. #The explicit OAuth 2.0 flow consists of the following steps: 1. Send a user to https://stackexchange.com/oauth, with these query string parameters - client_id - scope - redirect_uri - must be under an apps registered domain - state - optional 2. The user approves your app 3. The user is redirected to redirect_uri, with these query string parameters - code - state - optional, only returned if provided in the first step 4. POST (application/x-www-form-urlencoded) the following parameters to https://stackexchange.com/oauth/access_token - client_id - client_secret - code - from the previous step - redirect_uri - must be the same as the provided in the first step This request is responded to with either an error (HTTP status code 400) or an access token of the form access_token=...&expires=1234. expires will only be set if scope does not include no_expiry, the use of which is strongly advised against unless your app truly needs perpetual access. #The implicit OAuth 2.0 flow consists of the following steps: 1. Open a new window at https://stackexchange.com/oauth/dialog, with these query string parameters - client_id - scope (details) - redirect_uri - must be under an apps registered domain - state - optional 2. The user approves your app 3. The user is redirected to redirect_uri, with these parameters in the hash - access_token - expires - optional, only if scope doesn't contain no_expiry The explicit flow should be used by server-side applications, with special care taken to never leak client_secret. Client side applications should use the implicit flow. Once you have authenticated a user once, regardless of flow, subsequent re-authorizations will occur without requiring user action. Naturally, should a user revoke an applications permissions then further action will be required to re-authorize. Applications using the implicit flow can make use of our provided minimalistic Javascript SDK. #Scope With an empty scope, authentication will only allow an application to identify a user via the /me method. In order to access other information, different scope values must be sent. Multiple values may be sent in scope by comma or space delimitting them. - read_inbox - access a user's global inbox - no_expiry - access_token's with this scope do not expire - write_access - perform write operations as a user 2.1 - private_info - access full history of a user's private actions on the site 2.1 #Desktop Applications Desktop applications cannot participate directly in OAuth 2.0 flows, however the embeddable browser controls available in most frameworks make it possible to work around this limitation. Desktop applications should use the implicit client-side flow, hosting the process within a browser control. For redirect_uri, a value of https://stackexchange.com/oauth/login_success should be used. Upon a successful authentication, access_token will be placed in the url hash as with a standard implicit authentication. #Usage Access tokens can be passed (as access_token) to any method to grant applications an increased throttle quota. When passing an access token an app must pass its request key as well, if you don't have a request key you can obtain one by registering your application on Stack Apps (http://stackapps.com/users/login?returnurl=/apps/oauth/register). type: oauth2 flows: implicit: authorizationUrl: https://stackexchange.com/oauth scopes: {} schemas: access_tokens: items: properties: access_token: type: string account_id: type: integer expires_on_date: type: integer scope: items: {} type: array type: object type: array account_merge: items: properties: merge_date: type: integer new_account_id: type: integer old_account_id: type: integer type: object type: array answers: items: properties: accepted: type: boolean answer_id: type: integer awarded_bounty_amount: type: integer awarded_bounty_users: items: {} type: array body: type: string body_markdown: type: string can_flag: type: boolean comment_count: type: integer comments: items: {} type: array community_owned_date: type: integer creation_date: type: integer down_vote_count: type: integer downvoted: type: boolean is_accepted: type: boolean last_activity_date: type: integer last_edit_date: type: integer last_editor: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object link: type: string locked_date: type: integer owner: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object question_id: type: integer score: type: integer share_link: type: string tags: items: {} type: array title: type: string up_vote_count: type: integer upvoted: type: boolean type: object type: array badges: items: properties: award_count: type: integer badge_id: type: integer badge_type: type: string description: type: string link: type: string name: type: string rank: type: string user: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object type: object type: array comments: items: properties: body: type: string body_markdown: type: string can_flag: type: boolean comment_id: type: integer creation_date: type: integer edited: type: boolean link: type: string owner: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object post_id: type: integer post_type: type: string reply_to_user: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object score: type: integer upvoted: type: boolean type: object type: array created_comment: properties: body: type: string body_markdown: type: string can_flag: type: boolean comment_id: type: integer creation_date: type: integer edited: type: boolean link: type: string owner: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object post_id: type: integer post_type: type: string reply_to_user: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object score: type: integer upvoted: type: boolean type: object error: properties: error_id: type: number error_message: type: string error_name: type: string type: object errors: items: properties: description: type: string error_id: type: integer error_name: type: string type: object type: array events: items: properties: creation_date: type: integer event_type: type: string excerpt: type: string link: type: string "the id of the object (answer, comment, question, or user) the event describes": type: integer type: object type: array filters: items: properties: filter: type: string filter_type: type: string included_fields: items: {} type: array type: object type: array inbox_items: items: properties: answer_id: type: integer body: type: string comment_id: type: integer creation_date: type: integer is_unread: type: boolean item_type: type: string link: type: string question_id: type: integer site: properties: aliases: items: {} type: array api_site_parameter: type: string audience: type: string closed_beta_date: type: integer favicon_url: type: string high_resolution_icon_url: type: string icon_url: type: string launch_date: type: integer logo_url: type: string markdown_extensions: items: {} type: array name: type: string open_beta_date: type: integer related_sites: items: {} type: array site_state: type: string site_type: type: string site_url: type: string styling: properties: link_color: type: string tag_background_color: type: string tag_foreground_color: type: string type: object twitter_account: type: string type: object title: type: string type: object type: array info_object: properties: answers_per_minute: type: number api_revision: type: string badges_per_minute: type: number new_active_users: type: integer questions_per_minute: type: number site: properties: aliases: items: {} type: array api_site_parameter: type: string audience: type: string closed_beta_date: type: integer favicon_url: type: string high_resolution_icon_url: type: string icon_url: type: string launch_date: type: integer logo_url: type: string markdown_extensions: items: {} type: array name: type: string open_beta_date: type: integer related_sites: items: {} type: array site_state: type: string site_type: type: string site_url: type: string styling: properties: link_color: type: string tag_background_color: type: string tag_foreground_color: type: string type: object twitter_account: type: string type: object total_accepted: type: integer total_answers: type: integer total_badges: type: integer total_comments: type: integer total_questions: type: integer total_unanswered: type: integer total_users: type: integer total_votes: type: integer type: object network_users: items: properties: account_id: type: integer answer_count: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object creation_date: type: integer last_access_date: type: integer question_count: type: integer reputation: type: integer site_name: type: string site_url: type: string top_answers: items: {} type: array top_questions: items: {} type: array user_id: type: integer user_type: type: string type: object type: array notifications: items: properties: body: type: string creation_date: type: integer is_unread: type: boolean notification_type: type: string post_id: type: integer site: properties: aliases: items: {} type: array api_site_parameter: type: string audience: type: string closed_beta_date: type: integer favicon_url: type: string high_resolution_icon_url: type: string icon_url: type: string launch_date: type: integer logo_url: type: string markdown_extensions: items: {} type: array name: type: string open_beta_date: type: integer related_sites: items: {} type: array site_state: type: string site_type: type: string site_url: type: string styling: properties: link_color: type: string tag_background_color: type: string tag_foreground_color: type: string type: object twitter_account: type: string type: object type: object type: array posts: items: properties: body: type: string body_markdown: type: string comment_count: type: integer comments: items: {} type: array creation_date: type: integer down_vote_count: type: integer downvoted: type: boolean last_activity_date: type: integer last_edit_date: type: integer last_editor: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object link: type: string owner: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object post_id: type: integer post_type: type: string score: type: integer share_link: type: string title: type: string up_vote_count: type: integer upvoted: type: boolean type: object type: array privileges: items: properties: description: type: string reputation: type: integer short_description: type: string type: object type: array question_timeline_events: items: properties: comment_id: type: integer creation_date: type: integer down_vote_count: type: integer owner: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object post_id: type: integer question_id: type: integer revision_guid: type: string timeline_type: type: string up_vote_count: type: integer user: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object type: object type: array questions: items: properties: accepted_answer_id: type: integer answer_count: type: integer answers: items: {} type: array body: type: string body_markdown: type: string bounty_amount: type: integer bounty_closes_date: type: integer bounty_user: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object can_close: type: boolean can_flag: type: boolean close_vote_count: type: integer closed_date: type: integer closed_details: properties: by_users: items: {} type: array description: type: string on_hold: type: boolean original_questions: items: {} type: array reason: type: string type: object closed_reason: type: string comment_count: type: integer comments: items: {} type: array community_owned_date: type: integer creation_date: type: integer delete_vote_count: type: integer down_vote_count: type: integer downvoted: type: boolean favorite_count: type: integer favorited: type: boolean is_answered: type: boolean last_activity_date: type: integer last_edit_date: type: integer last_editor: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object link: type: string locked_date: type: integer migrated_from: properties: on_date: type: integer other_site: properties: aliases: items: {} type: array api_site_parameter: type: string audience: type: string closed_beta_date: type: integer favicon_url: type: string high_resolution_icon_url: type: string icon_url: type: string launch_date: type: integer logo_url: type: string markdown_extensions: items: {} type: array name: type: string open_beta_date: type: integer related_sites: items: {} type: array site_state: type: string site_type: type: string site_url: type: string styling: properties: link_color: type: string tag_background_color: type: string tag_foreground_color: type: string type: object twitter_account: type: string type: object question_id: type: integer type: object migrated_to: properties: on_date: type: integer other_site: properties: aliases: items: {} type: array api_site_parameter: type: string audience: type: string closed_beta_date: type: integer favicon_url: type: string high_resolution_icon_url: type: string icon_url: type: string launch_date: type: integer logo_url: type: string markdown_extensions: items: {} type: array name: type: string open_beta_date: type: integer related_sites: items: {} type: array site_state: type: string site_type: type: string site_url: type: string styling: properties: link_color: type: string tag_background_color: type: string tag_foreground_color: type: string type: object twitter_account: type: string type: object question_id: type: integer type: object notice: properties: body: type: string creation_date: type: integer owner_user_id: type: integer type: object owner: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object protected_date: type: integer question_id: type: integer reopen_vote_count: type: integer score: type: integer share_link: type: string tags: items: {} type: array title: type: string up_vote_count: type: integer upvoted: type: boolean view_count: type: integer type: object type: array reputation_changes: items: properties: link: type: string on_date: type: integer post_id: type: integer post_type: type: string reputation_change: type: integer title: type: string user_id: type: integer vote_type: type: string type: object type: array reputation_history: items: properties: creation_date: type: integer post_id: type: integer reputation_change: type: integer reputation_history_type: type: string user_id: type: integer type: object type: array reputation_objects: items: properties: link: type: string on_date: type: integer post_id: type: integer post_type: type: string reputation_change: type: integer title: type: string user_id: type: integer vote_type: type: string type: object type: array revisions: items: properties: body: type: string comment: type: string creation_date: type: integer is_rollback: type: boolean last_body: type: string last_tags: items: {} type: array last_title: type: string post_id: type: integer post_type: type: string revision_guid: type: string revision_number: type: integer revision_type: type: string set_community_wiki: type: boolean tags: items: {} type: array title: type: string user: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object type: object type: array single_filter: properties: filter: type: string filter_type: type: string included_fields: items: {} type: array type: object sites: items: properties: aliases: items: {} type: array api_site_parameter: type: string audience: type: string closed_beta_date: type: integer favicon_url: type: string high_resolution_icon_url: type: string icon_url: type: string launch_date: type: integer logo_url: type: string markdown_extensions: items: {} type: array name: type: string open_beta_date: type: integer related_sites: items: {} type: array site_state: type: string site_type: type: string site_url: type: string styling: properties: link_color: type: string tag_background_color: type: string tag_foreground_color: type: string type: object twitter_account: type: string type: object type: array suggested-edits: items: properties: approval_date: type: integer body: type: string comment: type: string creation_date: type: integer post_id: type: integer post_type: type: string proposing_user: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object rejection_date: type: integer suggested_edit_id: type: integer tags: items: {} type: array title: type: string type: object type: array tag_score_objects: items: properties: post_count: type: integer score: type: integer user: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object type: object type: array tag_synonyms: items: properties: applied_count: type: integer creation_date: type: integer from_tag: type: string last_applied_date: type: integer to_tag: type: string type: object type: array tag_wikis: items: properties: body: type: string body_last_edit_date: type: integer excerpt: type: string excerpt_last_edit_date: type: integer last_body_editor: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object last_excerpt_editor: properties: accept_rate: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object display_name: type: string link: type: string profile_image: type: string reputation: type: integer user_id: type: integer user_type: type: string type: object tag_name: type: string type: object type: array tags: items: properties: count: type: integer has_synonyms: type: boolean is_moderator_only: type: boolean is_required: type: boolean last_activity_date: type: integer name: type: string synonyms: items: {} type: array user_id: type: integer type: object type: array top_tag_objects: items: properties: answer_count: type: integer answer_score: type: integer question_count: type: integer question_score: type: integer tag_name: type: string user_id: type: integer type: object type: array user: properties: about_me: type: string accept_rate: type: integer account_id: type: integer age: type: integer answer_count: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object creation_date: type: integer display_name: type: string down_vote_count: type: integer is_employee: type: boolean last_access_date: type: integer last_modified_date: type: integer link: type: string location: type: string profile_image: type: string question_count: type: integer reputation: type: integer reputation_change_day: type: integer reputation_change_month: type: integer reputation_change_quarter: type: integer reputation_change_week: type: integer reputation_change_year: type: integer timed_penalty_date: type: integer up_vote_count: type: integer user_id: type: integer user_type: type: string view_count: type: integer website_url: type: string type: object user_timeline_objects: items: properties: badge_id: type: integer comment_id: type: integer creation_date: type: integer detail: type: string link: type: string post_id: type: integer post_type: type: string suggested_edit_id: type: integer timeline_type: type: string title: type: string user_id: type: integer type: object type: array users: items: properties: about_me: type: string accept_rate: type: integer account_id: type: integer age: type: integer answer_count: type: integer badge_counts: properties: bronze: type: integer gold: type: integer silver: type: integer type: object creation_date: type: integer display_name: type: string down_vote_count: type: integer is_employee: type: boolean last_access_date: type: integer last_modified_date: type: integer link: type: string location: type: string profile_image: type: string question_count: type: integer reputation: type: integer reputation_change_day: type: integer reputation_change_month: type: integer reputation_change_quarter: type: integer reputation_change_week: type: integer reputation_change_year: type: integer timed_penalty_date: type: integer up_vote_count: type: integer user_id: type: integer user_type: type: string view_count: type: integer website_url: type: string type: object type: array write_permissions: items: properties: can_add: type: boolean can_delete: type: boolean can_edit: type: boolean max_daily_actions: type: integer min_seconds_between_actions: type: integer object_type: type: string user_id: type: integer type: object type: array