---
title: "Document360 API Response: JSON Schema for Success and Error Handling"
slug: "responses"
description: "Understand the complete structure of Document360 API responses. Learn how to handle success and error responses in JSON, including field descriptions, error objects, and best practices for API integration."
updated: 2026-03-26T07:46:22Z
published: 2026-04-02T11:29:58Z
canonical: "apidocs.document360.com/responses"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://apidocs.document360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# API response format

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.

```json
{
    "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.

```json
{
  "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.

---

### FAQ

****How do I see the published status for all available languages?****

Set the `isPublished`parameter to false when retrieving articles, categories, or documents. This returns every language the article exists in, including languages that only have a draft and have never been published. This gives you a complete view of all languages and their publish states for that content.

The languages listed under Available Languages depend on whether you are filtering for published content or all content using the `isPublished `parameter.

- Published content only (`isPublished`=true): Shows only languages where the article has been published at least once, including languages that have a newer draft on top of an existing published version.
- All content (`isPublished`=false): Shows every language the article exists in, including languages that only have a draft and have never been published.

For example,

| Language | Status |
| --- | --- |
| French, German, Japanese | Published |
| Czech | Published, but has a newer draft |
| Spanish, Portuguese | Draft only — never published |

- If `isPublished `= true: Available Languages: French, German, Japanese, Czech
- If `isPublished `= false: Available Languages: French, German, Japanese, Czech, Spanish, Portuguese

This applies when retrieving articles, categories, and documents.

****Does delete response include slug?****

Yes. The webhook notification triggered when an article is deleted now includes a Slugs field, which returns the slugs of the deleted article across all languages it was available in.

This means if you cache article content, you can instantly identify and remove the right entries from your cache as soon as the webhook fires, without making any additional API calls.

```json
{
  "Knowledge base name": "My Knowledge Base",
  "Event": "Article deleted",
  "User": "John Doe",
  "User email": "johndoe@example.com",
  "Logged on (UTC)": "02/13/2026 10:57:16",
  "Article name": "Getting Started Guides",
  "Article id": "24a4e58a-9d64-453c-8f00-4159eb94b82e",
  "Language": "English",
  "Project version id": "0644e0fe-2ae1-4d16-a993-98b81524d5c4",
  "Language code": "en",
  "Slugs": [
    { "language": "en", "slug": "getting-started" },
    { "language": "fr", "slug": "demarrer" },
    { "language": "de", "slug": "erste-schritte" }
  ]
}
```

****Can readers still access Knowledge base site during Document360 portal downtime?****

Yes. GET calls of the Customer API now run independently of the Document360 portal, so your readers can continue accessing the site even during scheduled maintenance or portal downtime.