To retrieve object representations, clients make HTTP requests to object references. The server supplies these references as href attribute values in responses to GET requests.

Every vCloud Director installation has a well-known URL from which an unauthenticated user can retrieve a SupportedVersions document, which lists each version of the vCloud API that the server supports. For each version, the response lists the names and MIME types of the complex types defined in the version's XML namespace, and the version login URL. A system administrator can use that URL to authenticate to the cloud by logging in to the System organization. An authenticated user can discover other vCloud API URLs by making GET requests to URLs retrieved from the login response, and the URLs contained in responses to those requests. See Exploring a Cloud.

Requests are typically categorized by the type of requested operation: create, retrieve, update, and delete. This sequence of verbs is often abbreviated with the acronym CRUD. Each type of request is characterized by the use of specific HTTP verb to access a URL found in a Link element that has an operation-specific value for its rel (relation) attribute.

CRUD Operations Summary

Operation Type


Link Relation

Operation Summary




Creates a new object.




Retrieves the representation of an existing object in its current state.




Modifies an existing object.




Deletes an existing object. If the object is a container, you must remove all of its contents before you can delete it.

For example, this Link element indicates that you can use the URL to update the Org object that contains it.

   href="" />

The implied HTTP verb is PUT.


Request bodies must contain all required elements and attributes, even if you are not changing their values. Because optional elements and attributes typically revert to default values if they are omitted or empty, it is a best practice to include optional elements in request bodies that modify existing objects. Link elements and href attributes from responses do not need to be included in modified sections. Some elements and attributes are read-only and cannot be modified. See the schema reference for details.

HTTP communications between a vCloud API client and server are secured with SSL. API clients must also complete a login request to receive an authorization token that must be included in all subsequent requests.

The following HTTP headers are typically included in vCloud API requests:


All requests must include an HTTP Accept header that designates the vCloud API version that the client is using. Two forms of this header are supported:

Accept: application/*;version=api-version
Accept: application/vnd.vmware.vcloud.type+xml;version=api-version

The second form constrains acceptable responses to a type defined the vCloud API schema. For example, the following header indicates that the request is from a vCloud API version 5.6 client, and will accept any type defined in that API version:

Accept: application/*;version=5.6

In general, client requests can access objects defined by any version of the vCloud API that is less than or equal to the version specified in the Accept header. See API Versions.


Accept headers of the following form are also allowed in vCloud API requests, but they are not compliant with RFC 2616 and might be rejected by future versions of the vCloud API.

Accept: application/*+xml;version=api-version


By default, the system returns response content as uncompressed XML. Compressing the response can improve performance, especially when the response is large and network bandwidth is a factor. (Requests cannot be compressed.) To request a response to be returned as compressed XML, include the following header:

Accept-Encoding: gzip

The response is encoded using gzip encoding as described in RFC 1952, and includes the following header:

Content-Encoding: gzip

In the default configuration, responses smaller than 64KB are never compressed.


Message strings in ErrorType responses are localized. To specify the language desired in responses, use the Accept-Language request header. To request a response with message strings localized to French, use the following header:

Accept-Language: fr


All requests to create a vCloud API session must include an Authorization header of the form prescribed by the identity provider that your organization uses. See Create a vCloud API Session.


Requests that include a body must include an appropriate HTTP Content-Type header. Content types for all elements are listed in the schema reference. In addition, the type attribute of a response body indicates the content type of the document. For example, this response fragment indicates that the content type associated with a CatalogItem object is application/vnd.vmware.vcloud.catalogItem+xml.

   name="Ubuntu Template with vsftpd"
... />

A POST or PUT request that supplies a CatalogItem in the request body requires the following Content-Type header:

Content-Type: application/vnd.vmware.vcloud.catalogItem+xml

When it appears as the value of a Content-Type header or the type attribute of an element in the vCloud API, this string is case-insensitive in requests, and can be returned in either mixed case or lowercase characters in responses.


This header, which is returned with the Session response after a successful log-in, must be included in all subsequent requests from clients that authenticate to the integrated identity provider (see Create a Session Using Basic Authentication) or the SAML identity provider (see Create a Session Using SAML Authentication).


Clients that authenticate to the OAuth identity provider can include either the x-vcloud-authorization header or the OAuth Authorization: Bearer header to authorize a request. See Create a Session Using OAuth Authentication.


The value of this header is used to build a request ID returned in the value of the X-VMWARE-VCLOUD-REQUEST-ID header (see Response Headers). The value of this header cannot contain more than 128 characters drawn from the set of letters, numbers, and the hyphen (-). Values with invalid characters are ignored. Values with more than 128 characters are truncated.

vCloud Director uses a validating XML parser that requires elements in a request body to agree with the schema in order and number. Request bodies are rejected as invalid unless they meet the following criteria:

XML namespace attributes must be supplied for all namespaces represented by elements in the request. See XML Namespace Identifiers.

If multiple namespaces are represented in the request, XML namespace attributes must include an identifying prefix, and that prefix must be used with all elements from that namespace.

All required elements must appear in request bodies. All elements that appear in request bodies must appear in the order that the schema establishes, and with content that conforms to the type constraint that the schema specifies.

To guard against denial-of-service attacks, vCloud Director imposes the following limits on vCloud API requests:

Requests cannot exceed 512 KB.

Requests cannot contain more than 4096 XML elements.

Requests cannot have a depth greater than 100.