openapi-directory/api/stackexchange.com.json

Building & bundling https://github.com/APIs-guru/openapi-directory for easy use from JS

{"openapi":"3.0.0","servers":[{"url":"https://api.stackexchange.com/2.0"}],"info":{"description":"Stack Exchange is a network of 130+ Q&A communities including Stack Overflow.\n","title":"StackExchange","version":"2.0","x-apisguru-categories":["collaboration","developer_tools","support"],"x-issues":["https://github.com/APIs-guru/openapi-directory/issues/699","https://github.com/APIs-guru/openapi-directory/issues/217"],"x-logo":{"url":"http://sstatic.net/stackexchange/img/se-logo.png"},"x-origin":[{"format":"openapi","url":"https://raw.githubusercontent.com/APIs-guru/unofficial_openapi_specs/master/stackexchange.com/2.0/openapi.yaml","version":"3.0"}],"x-providerName":"stackexchange.com","x-tags":["helpWanted"],"x-unofficialSpec":true},"externalDocs":{"url":"https://api.stackexchange.com/"},"paths":{"/access-tokens/{accessTokens}":{"get":{"description":"Reads the properties for a set of access tokens.\n \n{accessTokens} can contain up to 20 access tokens. These are obtained by authenticating a user using OAuth 2.0.\n \nThis method returns a list of access_tokens.\n","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\n\nThe Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users.\n\nAn application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.\n\nFilters are immutable and non-expiring. An application can safely \"bake in\" any filters that are created, it is not necessary (or advisable) to create filters at runtime.\n\nThe motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).\n\n#Safety\n\nFilters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.\n\nNote that this does not mean that \"safe\" filter is mearly an \"unsafe\" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).\n\nWhen using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the \"safe\" data is the only accessible data it will be returned even in \"unsafe\" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.\n\n#Built In Filters\n\nThe following filters are built in:\n\ndefault, each type documents which fields are returned under the default filter (for example, answers).\nwithbody, which is default plus the *.body fields\nnone, which is empty\ntotal, which includes just .total\n\n#Compatibility with V1.x\n\nFor ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.\n","in":"query","name":"filter","schema":{"type":"string"}},{"description":"All API responses are JSON, we do support JSONP with the callback query parameter.\n","in":"query","name":"callback","schema":{"type":"string"}}],"responses":{"200":{"content":{"*/*":{"schema":{"$ref":"#/components/schemas/access_tokens"}}},"description":"OK"},"400":{"description":"bad_parameter – 400 An invalid parameter was passed, this includes even \"high level\" parameters like key or site.\n"},"401":{"description":"access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.\n"},"402":{"description":"invalid_access_token – 402 An invalid access token was passed to a method.\n"},"403":{"description":"access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.\n"},"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.\n"},"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.\n"},"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.\n"},"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.\n"},"502":{"description":"throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.\n"},"503":{"description":"temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.\n"}}}},"/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.\n \n{accessTokens} can contain up to 20 access tokens. These are obtained by authenticating a user using OAuth 2.0.\n \nThis method returns a list of access_tokens.\n","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\n\nThe Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users.\n\nAn application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.\n\nFilters are immutable and non-expiring. An application can safely \"bake in\" any filters that are created, it is not necessary (or advisable) to create filters at runtime.\n\nThe motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).\n\n#Safety\n\nFilters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.\n\nNote that this does not mean that \"safe\" filter is mearly an \"unsafe\" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).\n\nWhen using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the \"safe\" data is the only accessible data it will be returned even in \"unsafe\" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.\n\n#Built In Filters\n\nThe following filters are built in:\n\ndefault, each type documents which fields are returned under the default filter (for example, answers).\nwithbody, which is default plus the *.body fields\nnone, which is empty\ntotal, which includes just .total\n\n#Compatibility with V1.x\n\nFor ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.\n","in":"query","name":"filter","schema":{"type":"string"}},{"description":"All API responses are JSON, we do support JSONP with the callback query parameter.\n","in":"query","name":"callback","schema":{"type":"string"}}],"responses":{"200":{"content":{"*/*":{"schema":{"$ref":"#/components/schemas/access_tokens"}}},"description":"OK"},"400":{"description":"bad_parameter – 400 An invalid parameter was passed, this includes even \"high level\" parameters like key or site.\n"},"401":{"description":"access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.\n"},"402":{"description":"invalid_access_token – 402 An invalid access token was passed to a method.\n"},"403":{"description":"access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.\n"},"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.\n"},"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.\n"},"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.\n"},"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.\n"},"502":{"description":"throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.\n"},"503":{"description":"temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.\n"}}}},"/answers":{"get":{"description":"Returns all the undeleted answers in the system.\n \nThe sorts accepted by this method operate on the follow fields of the answer object:\n - activity - last_activity_date\n - creation - creation_date\n - votes - score\n  activity is the default sort.\n \n It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.\n\n \nThis method returns a list of answers.\n","parameters":[{"in":"query","name":"order","schema":{"enum":["desc","asc"],"type":"string"}},{"description":"sort = activity => date\nsort = creation => date\nsort = votes => number\n","in":"query","name":"max","schema":{"type":"string"}},{"description":"sort = activity => date\nsort = creation => date\nsort = votes => number\n","in":"query","name":"min","schema":{"type":"string"}},{"in":"query","name":"sort","schema":{"enum":["activity","creation","votes"],"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\n\nThe Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users.\n\nAn application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.\n\nFilters are immutable and non-expiring. An application can safely \"bake in\" any filters that are created, it is not necessary (or advisable) to create filters at runtime.\n\nThe motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).\n\n#Safety\n\nFilters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.\n\nNote that this does not mean that \"safe\" filter is mearly an \"unsafe\" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).\n\nWhen using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the \"safe\" data is the only accessible data it will be returned even in \"unsafe\" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.\n\n#Built In Filters\n\nThe following filters are built in:\n\ndefault, each type documents which fields are returned under the default filter (for example, answers).\nwithbody, which is default plus the *.body fields\nnone, which is empty\ntotal, which includes just .total\n\n#Compatibility with V1.x\n\nFor ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.\n","in":"query","name":"filter","schema":{"type":"string"}},{"description":"All API responses are JSON, we do support JSONP with the callback query parameter.\n","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.\n","in":"query","name":"site","required":true,"schema":{"type":"string"}}],"responses":{"200":{"content":{"*/*":{"schema":{"$ref":"#/components/schemas/answers"}}},"description":"OK"},"400":{"description":"bad_parameter – 400 An invalid parameter was passed, this includes even \"high level\" parameters like key or site.\n"},"401":{"description":"access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.\n"},"402":{"description":"invalid_access_token – 402 An invalid access token was passed to a method.\n"},"403":{"description":"access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.\n"},"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.\n"},"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.\n"},"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.\n"},"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.\n"},"502":{"description":"throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.\n"},"503":{"description":"temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.\n"}}}},"/answers/{ids}":{"get":{"description":"Gets the set of answers identified by ids.\n \nThis 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.\n \n{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for answer_id on answer objects.\n \nThe sorts accepted by this method operate on the follow fields of the answer object:\n - activity - last_activity_date\n - creation - creation_date\n - votes - score\n  activity is the default sort.\n \n It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.\n\n \nThis method returns a list of answers.\n","parameters":[{"description":"Number list (semicolon delimited).","in":"path","name":"ids","required":true,"schema":{"type":"string"}},{"in":"query","name":"order","schema":{"enum":["desc","asc"],"type":"string"}},{"description":"sort = activity => date\nsort = creation => date\nsort = votes => number\n","in":"query","name":"max","schema":{"type":"string"}},{"description":"sort = activity => date\nsort = creation => date\nsort = votes => number\n","in":"query","name":"min","schema":{"type":"string"}},{"in":"query","name":"sort","schema":{"enum":["activity","creation","votes"],"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\n\nThe Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users.\n\nAn application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.\n\nFilters are immutable and non-expiring. An application can safely \"bake in\" any filters that are created, it is not necessary (or advisable) to create filters at runtime.\n\nThe motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).\n\n#Safety\n\nFilters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.\n\nNote that this does not mean that \"safe\" filter is mearly an \"unsafe\" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).\n\nWhen using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the \"safe\" data is the only accessible data it will be returned even in \"unsafe\" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.\n\n#Built In Filters\n\nThe following filters are built in:\n\ndefault, each type documents which fields are returned under the default filter (for example, answers).\nwithbody, which is default plus the *.body fields\nnone, which is empty\ntotal, which includes just .total\n\n#Compatibility with V1.x\n\nFor ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.\n","in":"query","name":"filter","schema":{"type":"string"}},{"description":"All API responses are JSON, we do support JSONP with the callback query parameter.\n","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.\n","in":"query","name":"site","required":true,"schema":{"type":"string"}}],"responses":{"200":{"content":{"*/*":{"schema":{"$ref":"#/components/schemas/answers"}}},"description":"OK"},"400":{"description":"bad_parameter – 400 An invalid parameter was passed, this includes even \"high level\" parameters like key or site.\n"},"401":{"description":"access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.\n"},"402":{"description":"invalid_access_token – 402 An invalid access token was passed to a method.\n"},"403":{"description":"access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.\n"},"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.\n"},"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.\n"},"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.\n"},"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.\n"},"502":{"description":"throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.\n"},"503":{"description":"temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.\n"}}}},"/answers/{ids}/comments":{"get":{"description":"Gets the comments on a set of answers.\n \nIf 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.\n \n{ids} can contain up to 100 semicolon delimited ids, to find ids programatically look for answer_id on answer objects.\n \nThe sorts accepted by this method operate on the follow fields of the comment object:\n - creation - creation_date\n - votes - score\n  creation is the default sort.\n \n It is possible to create moderately complex queries using sort, min, max, fromdate, and todate.\n\n \nThis method returns a list of comments.\n","parameters":[{"description":"Number list (semicolon delimited).","in":"path","name":"ids","required":true,"schema":{"type":"string"}},{"in":"query","name":"order","schema":{"enum":["desc","asc"],"type":"string"}},{"description":"sort = creation => date\nsort = votes => number\n","in":"query","name":"max","schema":{"type":"string"}},{"description":"sort = creation => date\nsort = votes => number\n","in":"query","name":"min","schema":{"type":"string"}},{"in":"query","name":"sort","schema":{"enum":["creation","votes"],"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\n\nThe Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users.\n\nAn application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.\n\nFilters are immutable and non-expiring. An application can safely \"bake in\" any filters that are created, it is not necessary (or advisable) to create filters at runtime.\n\nThe motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).\n\n#Safety\n\nFilters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.\n\nNote that this does not mean that \"safe\" filter is mearly an \"unsafe\" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).\n\nWhen using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the \"safe\" data is the only accessible data it will be returned even in \"unsafe\" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.\n\n#Built In Filters\n\nThe following filters are built in:\n\ndefault, each type documents which fields are returned under the default filter (for example, answers).\nwithbody, which is default plus the *.body fields\nnone, which is empty\ntotal, which includes just .total\n\n#Compatibility with V1.x\n\nFor ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.\n","in":"query","name":"filter","schema":{"type":"string"}},{"description":"All API responses are JSON, we do support JSONP with the callback query parameter.\n","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.\n","in":"query","name":"site","required":true,"schema":{"type":"string"}}],"responses":{"200":{"content":{"*/*":{"schema":{"$ref":"#/components/schemas/comments"}}},"description":"OK"},"400":{"description":"bad_parameter – 400 An invalid parameter was passed, this includes even \"high level\" parameters like key or site.\n"},"401":{"description":"access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.\n"},"402":{"description":"invalid_access_token – 402 An invalid access token was passed to a method.\n"},"403":{"description":"access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.\n"},"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.\n"},"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.\n"},"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.\n"},"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.\n"},"502":{"description":"throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.\n"},"503":{"description":"temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.\n"}}}},"/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.\n \nThis method is meant for uninstalling applications, recovering from access_token leaks, or simply as a stronger form of /access-tokens/{accessTokens}/invalidate.\n \nNothing 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.\n \n{accessTokens} can contain up to 20 access tokens. These are obtained by authenticating a user using OAuth 2.0.\n \nThis method returns a list of access_tokens.\n","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\n\nThe Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users.\n\nAn application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.\n\nFilters are immutable and non-expiring. An application can safely \"bake in\" any filters that are created, it is not necessary (or advisable) to create filters at runtime.\n\nThe motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).\n\n#Safety\n\nFilters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.\n\nNote that this does not mean that \"safe\" filter is mearly an \"unsafe\" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).\n\nWhen using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the \"safe\" data is the only accessible data it will be returned even in \"unsafe\" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.\n\n#Built In Filters\n\nThe following filters are built in:\n\ndefault, each type documents which fields are returned under the default filter (for example, answers).\nwithbody, which is default plus the *.body fields\nnone, which is empty\ntotal, which includes just .total\n\n#Compatibility with V1.x\n\nFor ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.\n","in":"query","name":"filter","schema":{"type":"string"}},{"description":"All API responses are JSON, we do support JSONP with the callback query parameter.\n","in":"query","name":"callback","schema":{"type":"string"}}],"responses":{"200":{"content":{"*/*":{"schema":{"$ref":"#/components/schemas/access_tokens"}}},"description":"OK"},"400":{"description":"bad_parameter – 400 An invalid parameter was passed, this includes even \"high level\" parameters like key or site.\n"},"401":{"description":"access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.\n"},"402":{"description":"invalid_access_token – 402 An invalid access token was passed to a method.\n"},"403":{"description":"access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.\n"},"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.\n"},"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.\n"},"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.\n"},"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.\n"},"502":{"description":"throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.\n"},"503":{"description":"temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.\n"}}}},"/badges":{"get":{"description":"Returns all the badges in the system.\n \nBadge sorts are a tad complicated. For the purposes of sorting (and min/max) tag_based is considered to be greater than named.\n \nThis 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.\n \nFor 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.\n \nrank is the default sort.\n \nThis method returns a list of badges.\n","parameters":[{"in":"query","name":"inname","schema":{"type":"string"}},{"in":"query","name":"order","schema":{"enum":["desc","asc"],"type":"string"}},{"description":"sort = rank => string\nsort = name => string\nsort = type => string\n","in":"query","name":"max","schema":{"type":"string"}},{"description":"sort = rank => string\nsort = name => string\nsort = type => string\n","in":"query","name":"min","schema":{"type":"string"}},{"in":"query","name":"sort","schema":{"enum":["rank","name","type"],"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\n\nThe Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users.\n\nAn application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.\n\nFilters are immutable and non-expiring. An application can safely \"bake in\" any filters that are created, it is not necessary (or advisable) to create filters at runtime.\n\nThe motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).\n\n#Safety\n\nFilters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.\n\nNote that this does not mean that \"safe\" filter is mearly an \"unsafe\" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).\n\nWhen using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the \"safe\" data is the only accessible data it will be returned even in \"unsafe\" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.\n\n#Built In Filters\n\nThe following filters are built in:\n\ndefault, each type documents which fields are returned under the default filter (for example, answers).\nwithbody, which is default plus the *.body fields\nnone, which is empty\ntotal, which includes just .total\n\n#Compatibility with V1.x\n\nFor ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.\n","in":"query","name":"filter","schema":{"type":"string"}},{"description":"All API responses are JSON, we do support JSONP with the callback query parameter.\n","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.\n","in":"query","name":"site","required":true,"schema":{"type":"string"}}],"responses":{"200":{"content":{"*/*":{"schema":{"$ref":"#/components/schemas/badges"}}},"description":"OK"},"400":{"description":"bad_parameter – 400 An invalid parameter was passed, this includes even \"high level\" parameters like key or site.\n"},"401":{"description":"access_token_required – 401 A method that requires an access token (obtained via authentication) was called without one.\n"},"402":{"description":"invalid_access_token – 402 An invalid access token was passed to a method.\n"},"403":{"description":"access_denied – 403 A method which requires certain permissions was called with an access token that lacks those permissions.\n"},"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.\n"},"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.\n"},"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.\n"},"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.\n"},"502":{"description":"throttle_violation – 502 An application has violated part of the rate limiting contract, so the request was terminated.\n"},"503":{"description":"temporarily_unavailable – 503 Some or all of the API is unavailable. Applications should backoff on requests to the method invoked.\n"}}}},"/badges/name":{"get":{"description":"Gets all explicitly named badges in the system.\n \nA named badged stands in opposition to a tag-based badge. These are referred to as general badges on the sites themselves.\n \nFor 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.\n \nrank is the default sort.\n \nThis method returns a list of badges.\n","parameters":[{"in":"query","name":"inname","schema":{"type":"string"}},{"in":"query","name":"order","schema":{"enum":["desc","asc"],"type":"string"}},{"description":"sort = rank => string\nsort = name => string\n","in":"query","name":"max","schema":{"type":"string"}},{"description":"sort = rank => string\nsort = name => string\n","in":"query","name":"min","schema":{"type":"string"}},{"in":"query","name":"sort","schema":{"enum":["rank","name"],"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\n\nThe Stack Exchange API allows applications to exclude almost every field returned. For example, if an application did not care about a user's badge counts it could exclude user.badge_counts whenever it calls a method that returns users.\n\nAn application excludes fields by creating a filter (via /filter/create) and passing it to a method in the filter parameter.\n\nFilters are immutable and non-expiring. An application can safely \"bake in\" any filters that are created, it is not necessary (or advisable) to create filters at runtime.\n\nThe motivation for filters are several fold. Filters allow applications to reduce API responses to just the fields they are concerned with, saving bandwidth. With the list of fields an application is actually concerned with, the API can avoid unneccessary queries thereby decreasing response time (and reducing load on our infrastructure). Finally, filters allow us to be more conservative in what the API returns by default without a proliferation of parameters (as was seen with body, answers, and comments in the 1.x API family).\n\n#Safety\n\nFilters also carry a notion of safety, which is defined as follows. Any string returned as a result of an API call with a safe filter will be inline-able into HTML without script-injection concerns. That is to say, no additional sanitizing (encoding, HTML tag stripping, etc.) will be necessary on returned strings. Applications that wish to handle sanitizing themselves should create an unsafe filter. All filters are safe by default, under the assumption that double-encoding bugs are more desirable than script injections.\n\nNote that this does not mean that \"safe\" filter is mearly an \"unsafe\" one with all fields passed though UrlEncode(...). Many fields can and will contain HTML in all filter types (most notably, the *.body fields).\n\nWhen using unsafe filters, the API returns the highest fidelity data it can reasonably access for the given request. This means that in cases where the \"safe\" data is the only accessible data it will be returned even in \"unsafe\" filters. Notably the *.body fields are unchanged, as they are stored in that form. Fields that are unchanged between safe and unsafe filters are denoted in their types documentation.\n\n#Built In Filters\n\nThe following filters are built in:\n\ndefault, each type documents which fields are returned under the default filter (for example, answers).\nwithbody, which is default plus the *.body fields\nnone, which is empty\ntotal, which includes just .total\n\n#Compatibility with V1.x\n\nFor ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers so as to mimic the body, answers, and comments parameters that have been removed in V2.0. New applications should not use these filters.\n","in":"query","name":"filter","schema":{"type":"string"}},{"description":"All API responses are JSON, we do support JSONP with the callback query parameter.\n","in":"query","name":"callback","schema":{"type":"string"}},{"descr