# Error Handling

#### Error Response Structure

The API adheres to a standardized error response format to ensure consistent communication of errors. Below is a breakdown of the fields and examples:

**Fields in Error Response:**

* **type**: A URI reference to the documentation about the type of error.
* **title**: A short, human-readable summary of the problem type.
* **status**: The HTTP status code applicable to this error.
* **traceId**: A unique identifier for the error occurrence, helpful for debugging and tracing logs.
* **errors**: A dictionary containing detailed error messages from different layers of the application.

**Explanation of the `errors` Dictionary**

The `errors` field is designed to provide granular error details across the application's layers. This dictionary includes keys that specify the layer and function where the error occurred, with corresponding error messages.

* **business**: Represents errors from the business logic layer.
* **engine**: Represents errors from the engine or lower-level operations.

**Examples**

**Example 1: Business and Engine Layer Errors**

```json
{
    "errors": {
        "engine: AdCreativesByTemplates": [
            "No active notification channel configurations found for Application d5eabbb8-c0f6-4640-94fd-3566edad499f."
        ],
        "business: AdCreativesByTemplates": [
            "Not found error occurred while starting image render process."
        ]
    },
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "One or more errors occurred.",
    "status": 404,
    "detail": null,
    "instance": null,
    "extensions": {
        "traceId": "00-bacf1fb30e365a645a8b00cf3d4ed8f3-cd47bc0024a41426-00"
    }
}
```

This example highlights errors occurring first in the engine layer (`AdCreativesByTemplates` function) and subsequently propagated to the business layer. Each layer adds its error details to the `errors` dictionary.

**Example 2: Validation Error**

```json
{
  "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "traceId": "00-131a39782d3aa54ef0cfae62c715a4e2-61df78abdb62e43d-00",
  "errors": {
      "model": [
          "The model field is required."
      ],
      "$.applicationId": [
          "The JSON value could not be converted to System.Guid. Path: $.applicationId | LineNumber: 1 | BytePositionInLine: 56."
      ]
  }
}
```

This example demonstrates a validation error, where an invalid value for `applicationId` results in a failure.

**Example 3: Timeout Error**

```json
{
    "errors": {
        "business:": [
            "HttpClient: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing."
        ]
    },
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "An unexpected error occurred.",
    "status": 500,
    "detail": null,
    "instance": null,
    "extensions": {
        "traceId": "00-90ad77169df4211cd5d7fc6f18b90337-3e5cec4b638b3c38-00"
    }
}
```

This example demonstrates a timeout error in the business layer, where an HTTP request exceeded the configured timeout.

***

#### Summary

The structured error format provides transparency and actionable details for debugging and issue resolution, aiding developers in pinpointing and addressing issues efficiently.