API operations that return an error return one of the fault objects described in this section. All fault objects extend from the base fault, serviceFault, for easier exception handling for languages that support it.


The serviceFault, and by extension all other faults, includes message and details elements that contain strings that describe the nature of the fault. It also contain a code attribute that represents the HTTP response code. The code attribute of the fault is for the convenience of the caller, who can retrieve the response code from the HTTP response headers or directly from the fault object. Note that the serviceFault is not returned directly; instead one of the faults based on it is returned.


The badRequest fault indicates that the data in the request object is invalid. For example, a string was used in a parameter that accepts only an integer. The fault wraps validation errors.

Example: badRequest fault response

<badRequest xmlns="http://docs.openstack.org/loadbalancers/api/v1.0" code="400">
    <message>Validation fault</message>
    <details>The object is not valid</details>
            <message>Node ip is invalid. Please specify a valid ip.</message>


The immutableEntity fault is returned when you try to modify an item that is not currently in a state that allows modification. For example, load balancers with a status of PENDING_UPDATE, BUILD, or DELETED cannot be modified.

Example: immutableEntity fault response

<immutableEntity code="422" xmlns="http://docs.openstack.org/loadbalancers/api/v1.0">
    <message>The object at the specified URI is immutable and cannot be overwritten.</message>


The itemNotFound fault is returned when a requested resource is not found.

Example: itemNotFound fault response

<itemNotFound code="404" xmlns="http://docs.openstack.org/loadbalancers/api/v1.0">
    <message>Object not Found</message>


The loadBalancerFault fault is returned when an error occurs during a load balancer operation.

Example: loadBalancerFault fault response

<loadBalancerFault code="500" xmlns="http://docs.openstack.org/loadbalancers/api/v1.0">
    <message>An unknown exception has occurred. Please contact support.</message>


The outOfVirtualIps fault indicates that there are no virtual IP addresses left to assign to a new load balancer. In practice, this fault should not occur because virtual IP addresses are ordered as capacity is required. If you do experience this fault, contact Support so that we can make more IP addresses available.

Example: outOfVirtualIps fault response

<outOfVirtualIps code="500" xmlns="http://docs.openstack.org/loadbalancers/api/v1.0">
        Out of virtual IPs. Please contact support so they can allocate more virtual IPs.


The overLimit fault is returned when you exceed a currently allocated limit.

Example: overLimit fault response

<overLimit xmlns="http://docs.openstack.org/loadbalancers/api/v1.1"
    retryAfter="Retry-After [DATE ISO_8601]">
    <message>OverLimit Retry...</message>
    <details>Error Details...</details>


The serviceUnavailable fault is returned when the service is unavailable, such as when the service is undergoing maintenance. This fault does not necessarily mean that the currently configured load balancers are unable to process traffic; it simply means that the API is currently unable to service requests.

Example: serviceUnavailable fault response

<serviceUnavailable code="500" xmlns="http://docs.openstack.org/loadbalancers/api/v1.0">
    <message>The Load balancing service is currently not available</message>


The unauthorized fault is returned when you are not authorized to perform an attempted operation.

Example: unauthorized fault


No response body is returned for an unauthorized fault. A 401 status code header is returned during unsuccessful authentication to the Load Balancers API.


The unprocessableEntity fault is returned when an operation is requested on an item that does not support the operation, but the request is properly formed.


The Cloud Load Balancing API is considered asynchronous, which is why there is a status attribute on the load balancer. The API does not allow concurrent modifications on a single load balancer instance. If a concurrent modification is attempted, the unprocessableEntity fault is returned in the response. If you are using the API programmatically, we recommend that you issue a GET request to show load balancer details on the load balancer instance to verify that the status is ACTIVE before continuing any other modifications.

Example: unprocessableEntity fault response

<unprocessableEntity code="422" xmlns="http://docs.openstack.org/loadbalancers/api/v1.0">
    <message>The Object at the specified URI is unprocessable.</message>