Error Handling

Learn how to handle errors and exceptions when working with the iiniit API.

Overview

The iiniit API uses conventional HTTP response codes to indicate the success or failure of an API request. In general, codes in the 2xx range indicate success, codes in the 4xx range indicate an error that failed given the information provided (e.g., a required parameter was omitted), and codes in the 5xx range indicate an error with the iiniit servers.

This guide will help you understand how to handle errors from the iiniit API and implement robust error handling in your applications.

Error Response Format

When an error occurs, the API returns a JSON response with details about the error. The response includes the following fields:

{
  "error": {
    "code": "string",
    "message": "string",
    "innererror": { 
      "code": "string"
    },
    "details": []
  }
}
    
Field Description
error A machine-readable error code
error_description A human-readable description of the error
request_id A unique identifier for the request, useful for troubleshooting
documentation_url A URL to more information about the error

Error Response Properties

  • The code property contains a machine-readable value that you can take a dependency on in your code.

  • The innererror object might recursively contain more innererror objects with more specific error codes properties. When handling an error, apps should loop through all the nested error codes that are available and use the most detailed one that they understand.

  • The message property is a human-readable value that describes the error condition. Don't take any dependency on the content of this value in your code.

  • The message property at the root contains an error message intended for the developer to read. Error messages aren't localized and shouldn't be displayed directly to the user. When handling errors, your code shouldn't take any dependency on the message property values because they can change at any time, and they often contain dynamic information specific to the failed request. You should only code against error codes returned in code properties.

  • The details property is an optional array of error objects that have the same JSON format as the top-level error object. If a request is composed of multiple operations, such as a bulk or batch operation, it might be necessary to return an independent error for each operation. In this case, the details list is populated with these individual errors.

Tip: Always include the request_id when contacting support about an API error. This helps us identify and resolve your issue more quickly.

HTTP Status Codes

The iiniit API uses the following HTTP status codes:

Status code Status message Description
400 Bad Request Can't process the request because it's malformed or incorrect.
401 Unauthorized Required authentication information is either missing or not valid for the resource.
402 Payment Required The payment requirements for the API haven't been met.
403 Forbidden Access is denied to the requested resource. The user might not have enough permission or might not have a required license.

Important: If conditional access policies are applied to a resource, an HTTP 403; Forbidden error=insufficient_claims message may be returned.
404 Not Found The requested resource doesn’t exist.
405 Method Not Allowed The HTTP method in the request isn't allowed on the resource.
406 Not Acceptable This service doesn’t support the format requested in the Accept header.
409 Conflict The request can't be processed due to a conflict with the current state. For example, the specified parent folder might not exist. For a Directory_ConcurrencyViolation exception, you can repeat the request after some delay. The exponential backoff retry mechanism can be used. If a Retry-After header is present, that value can be used for the delay between retries.
410 Gone The requested resource is no longer available at the server.
411 Length Required A Content-Length header is required on the request.
412 Precondition Failed A precondition provided in the request (such as an if-match header) doesn't match the resource's current state.
413 Request Entity Too Large The request size exceeds the maximum limit.
415 Unsupported Media Type The content type of the request is a format that isn't supported by the service.
416 Requested Range Not Satisfiable The specified byte range is invalid or unavailable.
422 Unprocessable Entity Can't process the request because it is semantically incorrect.
423 Locked The resource that is being accessed is locked.
429 Too Many Requests Client application has been throttled and shouldn't attempt to repeat the request until an amount of time has elapsed.
500 Internal Server Error There was an internal server error while processing the request.
501 Not Implemented The requested feature isn’t implemented.
503 Service Unavailable The service is temporarily unavailable for maintenance or is overloaded. You may repeat the request after a delay, the length of which may be specified in a Retry-After header.
504 Gateway Timeout The server, while acting as a proxy, didn't receive a timely response from the upstream server it needed to access in attempting to complete the request.
507 Insufficient Storage The maximum storage quota has been reached.
509 Bandwidth Limit Exceeded Your app has been throttled for exceeding the maximum bandwidth cap. Your app can retry the request again after more time has elapsed.