Configuration API responses
Clients of the API should examine the HTTP response code to determine the success or failure of a request. The following table lists response codes and their meanings:
Response code | Description | Response body |
---|---|---|
200 Success |
The requested operation succeeded, with the response body being the configuration object that was created or modified. If further actions are required, they are included in the |
List of objects, or object properties, administrative actions. |
204 No Content |
The requested operation succeeded and no further information has been provided, such as in the case of a DELETE operation. |
None. |
400 Bad Request |
The request contents are incorrectly formatted or a request is made for an invalid API version. |
Error summary and optional message. |
401 Unauthorized |
User authentication is required. Some user agents such as browsers might respond by prompting for credentials. If the request had specified credentials in an Authorization header, they are invalid. |
None. |
403 Forbidden |
The requested operation is forbidden either because the user does not have sufficient privileges or some other constraint, such as an object is edit-only and cannot be deleted. |
None. |
404 Not Found |
The requested path does not refer to an existing object or object relation. |
Error summary and optional message. |
409 Conflict |
The requested operation could not be performed because of the current state of the configuration. For example, an attempt was made to create an object that already exists or an attempt was made to delete an object that is referred to by another object. |
Error summary and optional message. |
415 Unsupported Media Type |
The request is such that the Accept header does not indicate that JSON is an acceptable format for a response. |
None. |
500 Server Error |
The server encountered an unexpected error. Report server errors to customer support. |
Error Summary and optional message. |
An application that uses the Configuration API should limit dependencies on particular text appearing in error message content. These messages can change, and their presence might depend on server configuration. Use the HTTP return code and the context of the request to create a client error message. The following is an example encoded error message:
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:Error"
],
"status": 404,
"scimType": null,
"detail": "The Local DB Index does not exist."
}