{
  "swagger": "2.0",
  "info": {
    "version": "1.1.1",
    "title": "SOL003 - Virtualised Resources Quota Available Notification interface",
    "description": "SOL003 - Virtualised Resources Quota Available Notification interface\n\nIMPORTANT: Please note that this file might be not aligned to the current version of the ETSI Group Specification it refers to. In case of discrepancies the published ETSI Group Specification takes precedence.\n\nIn clause 4.3.2 of ETSI GS NFV-SOL 003 v2.4.1, an attribute-based filtering mechanism is defined. This mechanism is currently not included in the corresponding OpenAPI design for this GS version. Changes to the attribute-based filtering mechanism are being considered in v2.5.1 of this GS for inclusion in the corresponding future ETSI NFV OpenAPI design.\nPlease report bugs to https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=\n",
    "license": {
      "name": "ETSI Forge copyright notice",
      "url": "https://forge.etsi.org/etsi-forge-copyright-notice.txt"
    }
  },
  "externalDocs": {
    "description": "ETSI GS NFV-SOL 003 V2.4.1",
    "url": "http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.04.01_60/gs_NFV-SOL003v020401p.pdf"
  },
  "basePath": "/vrqan/v1",
  "schemes": [
    "https"
  ],
  "consumes": [
    "application/json"
  ],
  "produces": [
    "application/json"
  ],
  "paths": {
    "/subscriptions": {
      "post": {
        "description": "Subscribe\n\nThe POST method creates a new subscription. Creation of two subscription resources with the same callbackURI and the same filter can result in performance degradation and will provide duplicates of notifications to the VNFM, and might make sense only in very rare use cases. Consequently, the NFVO may either allow creating a subscription resource if another subscription resource with the same filter and callbackUri already exists (in which case it shall return the â€œ201 Createdâ€� response code), or may decide to not create a duplicate subscription resource (in which case it shall return a â€œ303 See Otherâ€� response code referencing the existing subscription resource with the same filter and callbackUri).\n",
        "parameters": [
          {
            "name": "Accept",
            "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
            "in": "header",
            "required": true,
            "type": "string"
          },
          {
            "name": "Authorization",
            "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
            "in": "header",
            "required": false,
            "type": "string"
          },
          {
            "name": "Content-Type",
            "description": "The Content-Type header shall be set to \"application/merge-patch+json\" according to IETF RFC 7396.\n",
            "in": "header",
            "required": true,
            "type": "string"
          },
          {
            "name": "VrQuotaAvailSubscriptionRequest",
            "description": "Details of the subscription to be created.",
            "in": "body",
            "required": true,
            "schema": {
              "description": "This type represents a subscription request related to notifications related to the availability of the virtualised resources quotas.\n",
              "type": "object",
              "required": [
                "callbackUri"
              ],
              "properties": {
                "filter": {
                  "description": "This type represents a subscription filter related to notifications about the availability of the virtualised resources quotas. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n",
                  "type": "object",
                  "properties": {
                    "vimIds": {
                      "description": "Match VIMs that were created the quota for a consumer of the virtualised resources. This attribute shall only be supported when VNF-related Resource Management in direct mode is applicable.\n",
                      "type": "array",
                      "items": {
                        "description": "An identifier with the intention of being globally unique.\n",
                        "type": "string"
                      }
                    },
                    "resourceProviderIds": {
                      "description": "Match the entities responsible for the management of the virtualised resources that were allocated by the NFVO. This attribute shall only be supported when VNF-related Resource Management in indirect mode is applicable. The identification scheme is outside the scope of the present document.\n",
                      "type": "array",
                      "items": {
                        "description": "An identifier with the intention of being globally unique.\n",
                        "type": "string"
                      }
                    },
                    "resourceTypes": {
                      "description": "Match particular resource types.\n",
                      "type": "array",
                      "items": {
                        "type": "string",
                        "enum": [
                          "COMPUTE",
                          "STORAGE",
                          "NETWORK"
                        ]
                      }
                    },
                    "resourceGroupIds": {
                      "description": "Match the \"infrastructure resource groups\" that are logical groupings of the virtualised resources assigned to a tenant within an infrastructure Domain.\n",
                      "type": "array",
                      "items": {
                        "description": "An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.\n",
                        "type": "string"
                      }
                    }
                  }
                },
                "callbackUri": {
                  "description": "String formatted according to IETF RFC 3986.\n",
                  "type": "string"
                },
                "authentication": {
                  "type": "object",
                  "required": [
                    "authType"
                  ],
                  "properties": {
                    "authType": {
                      "description": "Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use  HTTP Basic authentication with the client credentials. \n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the  notification endpoint, use an OAuth 2.0 Bearer token, obtained\n  using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent  over a mutually authenticated TLS session, i.e. not only the\n  server is authenticated, but also the client is authenticated\n  during the TLS tunnel setup.\n",
                      "type": "array",
                      "items": {
                        "type": "string",
                        "enum": [
                          "BASIC",
                          "OAUTH2_CLIENT_CREDENTIALS",
                          "TLS_CERT"
                        ]
                      }
                    },
                    "paramsBasic": {
                      "description": "Parameters for authentication/authorization using BASIC. Shall be present if authType is \"BASIC\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n",
                      "type": "object",
                      "properties": {
                        "userName": {
                          "description": "Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n",
                          "type": "string"
                        },
                        "password": {
                          "description": "Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n",
                          "type": "string"
                        }
                      }
                    },
                    "paramsOauth2ClientCredentials": {
                      "description": "Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n",
                      "type": "object",
                      "properties": {
                        "clientId": {
                          "description": "Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type.  Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n",
                          "type": "string"
                        },
                        "clientPassword": {
                          "description": "Client password to be used in the access token request of the OAuth 2.0 client credentials grant type.  Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n",
                          "type": "string"
                        },
                        "tokenEndpoint": {
                          "description": "String formatted according to IETF RFC 3986.\n",
                          "type": "string"
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        ],
        "responses": {
          "201": {
            "description": "Created\nRepresentation of the created subscription resource. The HTTP response shall include a \"Location\" HTTP header that points to the created subscription resource.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "Location": {
                "description": "The resource URI of the created VNF instance",
                "type": "string",
                "format": "url"
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "This type represents a subscription related to notifications related to the availability of the virtualised resources quotas.\n",
              "type": "object",
              "required": [
                "id",
                "callbackUri",
                "_links"
              ],
              "properties": {
                "id": {
                  "description": "An identifier with the intention of being globally unique.\n",
                  "type": "string"
                },
                "filter": {
                  "description": "This type represents a subscription filter related to notifications about the availability of the virtualised resources quotas. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n",
                  "type": "object",
                  "properties": {
                    "vimIds": {
                      "description": "Match VIMs that were created the quota for a consumer of the virtualised resources. This attribute shall only be supported when VNF-related Resource Management in direct mode is applicable.\n",
                      "type": "array",
                      "items": {
                        "description": "An identifier with the intention of being globally unique.\n",
                        "type": "string"
                      }
                    },
                    "resourceProviderIds": {
                      "description": "Match the entities responsible for the management of the virtualised resources that were allocated by the NFVO. This attribute shall only be supported when VNF-related Resource Management in indirect mode is applicable. The identification scheme is outside the scope of the present document.\n",
                      "type": "array",
                      "items": {
                        "description": "An identifier with the intention of being globally unique.\n",
                        "type": "string"
                      }
                    },
                    "resourceTypes": {
                      "description": "Match particular resource types.\n",
                      "type": "array",
                      "items": {
                        "type": "string",
                        "enum": [
                          "COMPUTE",
                          "STORAGE",
                          "NETWORK"
                        ]
                      }
                    },
                    "resourceGroupIds": {
                      "description": "Match the \"infrastructure resource groups\" that are logical groupings of the virtualised resources assigned to a tenant within an infrastructure Domain.\n",
                      "type": "array",
                      "items": {
                        "description": "An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.\n",
                        "type": "string"
                      }
                    }
                  }
                },
                "callbackUri": {
                  "description": "String formatted according to IETF RFC 3986.\n",
                  "type": "string"
                },
                "_links": {
                  "description": "Links for this resource\n",
                  "type": "object",
                  "required": [
                    "self"
                  ],
                  "properties": {
                    "self": {
                      "description": "This type represents a link to a resource.\n",
                      "type": "object",
                      "required": [
                        "href"
                      ],
                      "properties": {
                        "href": {
                          "description": "URI of the referenced resource.\n",
                          "type": "string",
                          "format": "url"
                        }
                      }
                    }
                  }
                }
              }
            }
          },
          "303": {
            "description": "See Other\nA subscription with the same callbackURI and the same filter already exists and the policy of the VNFM is to not create redundant subscriptions. The HTTP response shall include a \"Location\" HTTP header that contains the resource URI of the existing subscription resource. The response body shall be empty.\n"
          },
          "400": {
            "description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\n ---\n\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n ---\n\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code.The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "401": {
            "description": "Unauthorized\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "403": {
            "description": "Forbidden\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided.  It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "404": {
            "description": "Not Found\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "405": {
            "description": "Method Not Allowed\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "406": {
            "description": "Not Acceptable\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "500": {
            "description": "Internal Server Error\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "503": {
            "description": "Service Unavailable\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          }
        }
      },
      "get": {
        "description": "Query Subscription Information\n\nThe GET method allows the server to test the notification endpoint that is provided by the client, e.g. during subscription.\n",
        "parameters": [
          {
            "name": "Authorization",
            "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
            "in": "header",
            "required": false,
            "type": "string"
          }
        ],
        "responses": {
          "204": {
            "description": "No Content\nThe notification endpoint was tested successfully. The response body shall be empty.\n",
            "headers": {
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            }
          },
          "400": {
            "description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\n ---\n\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n ---\n\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code.The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "401": {
            "description": "Unauthorized\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "403": {
            "description": "Forbidden\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided.  It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "404": {
            "description": "Not Found\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "406": {
            "description": "Not Acceptable\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "500": {
            "description": "Internal Server Error\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "503": {
            "description": "Service Unavailable\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          }
        }
      }
    },
    "/subscriptions/{subscriptionId}": {
      "parameters": [
        {
          "name": "subscriptionId",
          "description": "Identifier of this subscription. This identifier can be retrieved from the resource referenced by the \"Location\" HTTP header in the response to a POST request creating a new subscription resource. It can also be retrieved from the \"id\" attribute in the payload body of that response.\n",
          "in": "path",
          "type": "string",
          "required": true
        }
      ],
      "get": {
        "description": "Query Subscription Information\n\nThe GET method reads an individual subscription.\n",
        "parameters": [
          {
            "name": "Accept",
            "description": "Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n",
            "in": "header",
            "required": true,
            "type": "string"
          },
          {
            "name": "Authorization",
            "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
            "in": "header",
            "required": true,
            "type": "string"
          }
        ],
        "responses": {
          "200": {
            "description": "OK\nRepresentation of the subscription resource.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "This type represents a subscription related to notifications related to the availability of the virtualised resources quotas.\n",
              "type": "object",
              "required": [
                "id",
                "callbackUri",
                "_links"
              ],
              "properties": {
                "id": {
                  "description": "An identifier with the intention of being globally unique.\n",
                  "type": "string"
                },
                "filter": {
                  "description": "This type represents a subscription filter related to notifications about the availability of the virtualised resources quotas. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n",
                  "type": "object",
                  "properties": {
                    "vimIds": {
                      "description": "Match VIMs that were created the quota for a consumer of the virtualised resources. This attribute shall only be supported when VNF-related Resource Management in direct mode is applicable.\n",
                      "type": "array",
                      "items": {
                        "description": "An identifier with the intention of being globally unique.\n",
                        "type": "string"
                      }
                    },
                    "resourceProviderIds": {
                      "description": "Match the entities responsible for the management of the virtualised resources that were allocated by the NFVO. This attribute shall only be supported when VNF-related Resource Management in indirect mode is applicable. The identification scheme is outside the scope of the present document.\n",
                      "type": "array",
                      "items": {
                        "description": "An identifier with the intention of being globally unique.\n",
                        "type": "string"
                      }
                    },
                    "resourceTypes": {
                      "description": "Match particular resource types.\n",
                      "type": "array",
                      "items": {
                        "type": "string",
                        "enum": [
                          "COMPUTE",
                          "STORAGE",
                          "NETWORK"
                        ]
                      }
                    },
                    "resourceGroupIds": {
                      "description": "Match the \"infrastructure resource groups\" that are logical groupings of the virtualised resources assigned to a tenant within an infrastructure Domain.\n",
                      "type": "array",
                      "items": {
                        "description": "An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.\n",
                        "type": "string"
                      }
                    }
                  }
                },
                "callbackUri": {
                  "description": "String formatted according to IETF RFC 3986.\n",
                  "type": "string"
                },
                "_links": {
                  "description": "Links for this resource\n",
                  "type": "object",
                  "required": [
                    "self"
                  ],
                  "properties": {
                    "self": {
                      "description": "This type represents a link to a resource.\n",
                      "type": "object",
                      "required": [
                        "href"
                      ],
                      "properties": {
                        "href": {
                          "description": "URI of the referenced resource.\n",
                          "type": "string",
                          "format": "url"
                        }
                      }
                    }
                  }
                }
              }
            }
          },
          "400": {
            "description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\n ---\n\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n ---\n\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code.The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "401": {
            "description": "Unauthorized\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "403": {
            "description": "Forbidden\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided.  It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "404": {
            "description": "Not Found\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "406": {
            "description": "Not Acceptable\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "500": {
            "description": "Internal Server Error\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "503": {
            "description": "Service Unavailable\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          }
        }
      },
      "delete": {
        "description": "Terminate subscription\n\nThe DELETE method terminates an individual subscription.\n",
        "parameters": [
          {
            "name": "Authorization",
            "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
            "in": "header",
            "required": true,
            "type": "string"
          }
        ],
        "responses": {
          "204": {
            "description": "No Content\nThe subscription resource was deleted successfully. The response body shall be empty.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the request. Reference: IETF RFC 7231\n",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            }
          },
          "400": {
            "description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem.\n ---\n\nIf the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n ---\n\nIf there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code.The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "401": {
            "description": "Unauthorized\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "403": {
            "description": "Forbidden\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided.  It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "405": {
            "description": "Method Not Allowed\nIf a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "406": {
            "description": "Not Acceptable\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "500": {
            "description": "Internal Server Error\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "503": {
            "description": "Service Unavailable\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          }
        }
      }
    }
  }
}