The Unauthenticated error indicates that the operation requires authentication and the user is not authenticated. API requests may include a security context containing user credentials. For example, the user credentials could be a SAML token, a user name and password, or the session identifier for a previously established session.


  • The SAML token in the request’s security context has expired.
  • The user name and password in the request’s security context are invalid.
  • The session identifier in the request’s security context identifies a session that has expired. Counterexamples:
  • The user is authenticated but isn’t authorized to perform the requested operation. The Unauthorized error would be used instead.

For security reasons, the field in this error is unset, and the Error.messages field in this error does not disclose which part of the security context is correct or incorrect. For example the messages would not disclose whether a username or a password is valid or invalid, but only that a combination of username and password is invalid.


challenge Optional

Indicates the authentication challenges applicable to the target API provider. It can be used by a client to discover the correct authentication scheme to use. The exact syntax of the value is defined by the specific provider, the protocol and authentication schemes used. For example, a provider using REST may adhere to the WWW-Authenticate HTTP header specification, RFC7235, section 4.1. In this case an example challenge value may be: SIGN realm=“27da1358-2ba4-11e9-b210-d663bd873d93”,sts=”http://vcenter/sso?vsphere.local”, Basic realm=“vCenter”

This field is optional because it was added in a newer version than its parent node.

data Optional

Data to facilitate clients responding to the operation reporting a standard error to indicating that it was unable to complete successfully. Operations may provide data that clients can use when responding to errors. Since the data that clients need may be specific to the context of the operation reporting the error, different operations that report the same error may provide different data in the error. The documentation for each each operation will describe what, if any, data it provides for each error it reports. The ArgumentLocations, FileLocations, and TransientIndication structures are intended as possible values for this field. DynamicID may also be useful as a value for this field (although that is not its primary purpose). Some services may provide their own specific structures for use as the value of this field when reporting errors from their operations.

Some operations will not set this field when reporting errors.

error_type Optional

Discriminator field to help API consumers identify the structure type. Can be unset for compatibility with preceding implementations.


messages Required

Stack of one or more localizable messages for human error consumers. The message at the top of the stack (first in the list) describes the error from the perspective of the operation the client invoked. Each subsequent message in the stack describes the “cause” of the prior message.

JSON Example

    "messages": [
            "args": [
            "default_message": "string",
            "id": "string"

Was this page helpful?