Overview
The WEDA API implements a standardized error response format based on RFC 9457 (Problem Details for HTTP APIs). This industry-standard specification provides a machine-readable, language-agnostic format for describing HTTP API errors, ensuring consistency and predictability across all API endpoints.
Why RFC 9457?
We adopted RFC 9457 to provide:
- Cross-platform compatibility - The standard JSON format works seamlessly across web, mobile, desktop, and embedded applications
- Language independence - Client applications can be built in any programming language (JavaScript, Java, C#, Python, Swift, Kotlin, etc.)
- Industry best practices - Aligns with modern API design standards used by major technology companies
- Future-proof architecture - As an IETF standard, RFC 9457 ensures long-term compatibility and tooling support
Benefits for API Consumers
This structured approach enables client applications to:
- Implement consistent error handling logic across the entire application, regardless of the platform or technology stack
- Display localized error messages to end users based on the
Accept-Languageheader, improving accessibility - Programmatically distinguish between different error types using the
typefield for intelligent error routing - Debug issues efficiently using
traceIdfor correlation with server logs and support diagnostics - Handle validation errors gracefully by mapping
validationItemsto specific input fields in the user interface - Reduce integration time by following a well-documented, predictable error format
Error Response Schema
All API errors return a structured JSON response conforming to RFC 9457. The response includes the following fields:
Standard Error Fields
| Field | Type | Description |
|---|---|---|
type | string | A URI reference that identifies the problem type. May be a full URI (e.g., https://api.example.com/problems/validation-error) or a simple error code (e.g., License.Expired). |
title | string | A short, human-readable summary of the problem type. This value is localized based on the request's Accept-Language header. |
status | integer | The HTTP status code (400, 401, 403, 404, 500, etc.). |
detail | string | A human-readable explanation specific to this occurrence of the problem. Runtime values are substituted into placeholders. |
detailFormat | string | A template string showing the format of the detail field with placeholder names (e.g., "The field {FieldName} is required."). |
instance | string | A URI reference identifying the specific occurrence of the problem, typically the API endpoint path. |
timestamp | string | ISO 8601 timestamp indicating when the error occurred (e.g., 2026-04-14T02:26:01.1247685+00:00). |
traceId | string | A unique identifier for this request, useful for debugging and correlating logs. |
extension | object | Additional custom properties specific to the error context. |
Validation Error Fields
For validation errors (HTTP 400), the response includes an additional validationItems array:
| Field | Type | Description |
|---|---|---|
validationItems | array | An array of validation error details. Only present when one or more input fields fail validation. |
Each item in the validationItems array contains:
| Field | Type | Description |
|---|---|---|
fieldName | string | The name of the field that failed validation. |
title | string | The error code for this validation failure (e.g., CommonModelError.RequiredError). |
detail | string | A human-readable explanation of the validation error with values substituted. |
detailFormat | string | The template string showing the format of the detail field with placeholder names. |
extension | object | Additional context-specific data about the validation failure (e.g., field constraints, values). |
Example: Validation Error Response
{
"type": "https://api.example.com/problems/validation-error",
"title": "ValidationError",
"status": 400,
"detail": "One or more properties is invalid, see the details",
"detailFormat": null,
"instance": "/api/v1/notifications/audit-logs",
"timestamp": "2026-04-14T02:26:01.1247685+00:00",
"traceId": "e00edf3ac5896f918770e70ef17b65b7",
"extension": null,
"validationItems": [
{
"fieldName": "EndTime",
"title": "CommonModelError.RequiredError",
"detail": "The field EndTime is required.",
"detailFormat": "The field {FieldName} is required.",
"extension": {
"fieldName": "EndTime",
"required": true
}
},
{
"fieldName": "StartTime",
"title": "CommonModelError.RequiredError",
"detail": "The field StartTime is required.",
"detailFormat": "The field {FieldName} is required.",
"extension": {
"fieldName": "StartTime",
"required": true
}
}
]
}
Internationalization Support
The WEDA API is designed with internationalization (i18n) support in mind.
- Always check the
statuscode to determine the error category (client error 4xx vs server error 5xx) - Use the
typefield for programmatic error handling and routing - Display the localized
titleto end users for better UX - For validation errors, iterate through
validationItemsto show field-specific error messages - Include the
traceIdwhen reporting issues to support teams for faster troubleshooting
How to Read Error Codes
Each error code follows the format Category.ErrorName.
| Component | Description |
|---|---|
Category | The module or domain the error belongs to (e.g. License, User) |
ErrorName | A descriptive identifier for the specific error condition |