Document360 API Response: JSON Schema for Success and Error Handling

All Document360 API responses are returned in JSON format and follow a consistent structure. Understanding this structure is essential for interpreting both successful and error responses programmatically.

Response Schema Overview

Each response includes these top-level fields:

success: Indicates whether the request was successful (true or false).
data: Contains the response payload, or null if no data is returned.
errors: An array of error objects, populated only when success is false.
extension_data, context, warnings, and information: Optional fields providing additional metadata or context.

Always check the success field first to determine the outcome of the request.

Success response

All successful responses follow the same structure. The success field is always set to true, and the data field contains the returned result (or null if no data is applicable). The errors array is always empty, while extension_data, warnings, and information may be populated based on the context of the request.

{
    "data": null, //actual response data, if any
    "extension_data": null, //additional metadata
    "context": null, //optional context about the request
    "success": true, //boolean, always true for successful responses
    "errors": [], //empty array (no errors in a successful response
    "warnings": [], //array of non-critical warningss, if any
    "information": [] //array with info about the request excecution
}

Success response fields

Field	Type	Description
`data`	object or null	Contains the actual response payload. Null if no data is returned.
`extension_data`	object or null	Contains additional metadata, such as processing details.
`context`	object or null	Used to pass context-specific values for advanced workflows.
`success`	boolean	Indicates whether the request was successful. Always `true` for success responses.
`errors`	array	Always an empty array in success responses.
`warnings`	array	May include non-blocking warning messages.
`information`	array	May contain descriptive details about the request execution (e.g., timing, processing info).

Error response

All error responses follow the same structure. The success field is always set to false, and the data field will be null. The errors array contains one or more error objects describing the issue. Fields like extension_data, warnings, and information may be included depending on the context. In debug or development environments, the stack_trace field may provide additional diagnostic details.

{
  "data": null,
  "extension_data": null, // additional metadata
  "context": null, // optional context about the request
  "success": false, // indicates the request was not successful
  "errors": [ 
    {
      "extension_data": null, // error-specific metadata
      "stack_trace": "", // stack trace for debugging (optional)
      "description": "", // description of the error
      "error_code": "" // machine-readable error identifier
    }
  ],
  "warnings": [], // optional non-blocking issues
  "information": [] // optional notes about request execution
}

Error response fields

Field	Type	Description
`data`	null	Always `null` in error responses.
`extension_data`	object or null	Additional metadata about the response.
`context`	object or null	Optional context about the request.
`success`	boolean	Always `false` for error responses.
`errors`	array	Contains one or more error objects with details about what went wrong.
`warnings`	array	May include non-critical issues not blocking the request.
`information`	array	May include execution info like timing, retry hints, etc.

Error object fields (inside `errors` array)

Field	Type	Description
`extension_data`	object or null	Additional metadata about this specific error.
`stack_trace`	string	Debugging trace of the error. Usually included only in non-production environments.
`description`	string	A human-readable explanation of the error.
`error_code`	string	A machine-readable error code, typically used for programmatic error handling.

Best practices

Always check the success flag before parsing data or errors.
Use error_code for automated error handling (e.g., AUTH_401, VALIDATION_400).
Review warnings and information arrays to detect deprecated usage or suggested improvements.
Do not rely on stack_trace in production environments; it may be omitted or sanitized.

API response format