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.
  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.
         
        {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":
          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.
        "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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/created_comment"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/errors"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/error"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/events"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/single_filter"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/filters"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/inbox_items"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/inbox_items"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/info_object"
          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.
  /me:
    get:
      description: |
        Returns the user associated with the passed access_token.
         
        This method returns a user.
      parameters:
        - in: query
          name: order
          schema:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - reputation
              - creation
              - name
              - modified
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/user"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/network_users"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - activity
              - creation
              - votes
              - added
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/inbox_items"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/inbox_items"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/account_merge"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/notifications"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/notifications"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/privileges"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/reputation_changes"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/reputation_history"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/reputation_history"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - creation
              - approval
              - rejection
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/suggested-edits"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - popular
              - activity
              - 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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tags"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            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: 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:
            enum:
              - activity
              - creation
              - votes
              - hot
              - week
              - month
              - relevance
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/user_timeline_objects"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/top_tag_objects"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/top_tag_objects"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/write_permissions"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/notifications"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/notifications"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/posts"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/posts"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/revisions"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - creation
              - approval
              - rejection
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/suggested-edits"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/created_comment"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/privileges"
          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.
  /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:
            enum:
              - desc
              - asc
            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: 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:
            enum:
              - activity
              - creation
              - votes
              - hot
              - week
              - month
              - relevance
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - activity
              - creation
              - votes
              - rank
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - activity
              - creation
              - votes
              - rank
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/question_timeline_events"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/revisions"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - activity
              - creation
              - votes
              - relevance
            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
        - in: query
          name: intitle
          schema:
            type: string
        - description: String list (semicolon delimited).
          in: query
          name: nottagged
          schema:
            type: string
      responses:
        "200":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - activity
              - creation
              - votes
              - relevance
            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
        - in: query
          name: accepted
          schema:
            enum:
              - true
              - false
            type: string
        - in: query
          name: answers
          schema:
            type: integer
        - in: query
          name: body
          schema:
            type: string
        - in: query
          name: closed
          schema:
            enum:
              - true
              - false
            type: string
        - in: query
          name: migrated
          schema:
            enum:
              - true
              - false
            type: string
        - in: query
          name: notice
          schema:
            enum:
              - true
              - false
            type: string
        - 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:
            enum:
              - true
              - false
            type: string
      responses:
        "200":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - activity
              - creation
              - votes
              - relevance
            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
        - description: String list (semicolon delimited).
          in: query
          name: nottagged
          schema:
            type: string
        - in: query
          name: title
          schema:
            type: string
      responses:
        "200":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  /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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/sites"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - creation
              - approval
              - rejection
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/suggested-edits"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - creation
              - approval
              - rejection
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/suggested-edits"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - popular
              - activity
              - 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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tags"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - popular
              - activity
              - 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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tags"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - popular
              - activity
              - 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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tags"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - creation
              - applied
              - activity
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tag_synonyms"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - popular
              - activity
              - 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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tags"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tags"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - creation
              - applied
              - activity
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tag_synonyms"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tag_wikis"
          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.
  "/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:
            enum:
              - all_time
              - month
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tag_score_objects"
          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.
  "/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:
            enum:
              - all_time
              - month
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tag_score_objects"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - reputation
              - creation
              - name
              - modified
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/users"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - reputation
              - creation
              - name
              - modified
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/users"
          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.
  /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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - reputation
              - creation
              - name
              - modified
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/users"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - reputation
              - creation
              - name
              - modified
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/users"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/network_users"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - rank
              - name
              - type
              - awarded
            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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - activity
              - creation
              - votes
              - added
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/account_merge"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/reputation_changes"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/reputation_history"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - creation
              - approval
              - rejection
            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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/suggested-edits"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            enum:
              - popular
              - activity
              - 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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/tags"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/user_timeline_objects"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/inbox_items"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/inbox_items"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/notifications"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/notifications"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/privileges"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/reputation_history"
          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.
  "/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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          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.
        "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:
            enum:
              - desc
              - asc
            type: string
        - 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:
            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

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

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

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

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

            #Safety

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

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

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

            #Built In Filters

            The following filters are built in:

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

            #Compatibility with V1.x

            For ease of transition from earlier API versions, the filters _b, _ba, _bc, _bca, _a, _ac, and _c are also built in. These are unsafe, and exclude a combination of question and answer body, comments, and answers 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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/questions"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/top_tag_objects"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/top_tag_objects"
          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.
  "/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":
          content:
            "*/*":
              schema:
                $ref: "#/components/schemas/write_permissions"
          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.
components:
  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
  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).
      flows:
        implicit:
          authorizationUrl: https://stackexchange.com/oauth
          scopes: {}
      type: oauth2
