Skip to content

Error Handling

Due to historical reasons there is no common error handling shared between the OneRoster and Untis Platform API families.


Most of the Untis Platform APIs follow a common error handling pattern defining structured JSON responses:

  • User Management
  • Student Management
  • Teacher Management
  • Legal Guardian Management
  • Class Management
  • Room Management
  • Lessons

Other APIs (e.g. Timetable or Messaging) use individual error handling with different response types.

These APIs all define the same HTTP error status set and the same two reusable error response schemas: ValidationErrorResponse and ErrorResponse.

HTTP statusResponse schemaMeaning
400ValidationErrorResponseRequest parameters are invalid
401ErrorResponseAuthentication missing or invalid
403ErrorResponseAuthenticated caller not allowed
404ErrorResponseRequested entity not found
500ErrorResponseUnexpected internal error

FieldDescription
errorCodeMachine-readable code identifying the error type.
errorMessageHuman-readable message describing the error.
requestIdUnique identifier for the API request. Use when contacting support or tracing logs.
traceIdIdentifier used for distributed tracing across services.
{
"errorCode": "FORBIDDEN",
"errorMessage": "Access denied.",
"requestId": "5f0c7f12-3a17-4a0b-9b1a-2d8f5c8d1234",
"traceId": "9e8f7a6b5c4d3210"
}

FieldDescription
errorCodeMachine-readable code identifying the error type.
requestIdUnique identifier for the API request. Use when contacting support or tracing logs.
traceIdIdentifier used for distributed tracing across services.
validationErrorsArray describing individual validation problems detected in the request.

validationErrors entry fields:

FieldRequiredDescription
pathyesLocation of the invalid field in the request payload or parameters. Start index is 0.
errorMessageyesHuman-readable description of the validation problem.
errorKeynoMachine-readable key identifying the specific validation rule that failed.
constraintValuenoThe constraint value associated with the validation rule (e.g. maximum length).
indexnoFor bulk operations — indicates which array element caused the error. Start index is 0.
errorDatanoAdditional structured information such as identifiers of related entities.
{
"errorCode": "VALIDATION_ERROR",
"requestId": "5f0c7f12-3a17-4a0b-9b1a-2d8f5c8d1234",
"traceId": "9e8f7a6b5c4d3210",
"validationErrors": [
{
"path": "students[0].externKey",
"errorMessage": "must not be blank",
"errorKey": "field.mustNotBeBlank",
"index": 0,
"constraintValue": "1"
}
]
}

The Classreg-Absences API defines error handling only through HTTP status codes. It does not define a common error response schema.

HTTP statusResponse schemaMeaning
400none definedInvalid request
401none definedAuthentication missing or invalid
403none definedAccess forbidden
500none definedUnexpected internal error

The Exam API defines error handling through HTTP status codes and a shared Error response object.

HTTP statusResponse schemaMeaning
400ErrorClient error / invalid request
500ErrorServer error
FieldRequiredDescription
titleyesShort, human-readable summary of the problem type.
statusyesThe HTTP status code.
detailnoHuman-readable explanation specific to this occurrence of the problem.
{
"title": "Bad Request",
"status": 400,
"detail": "At least one filter criterion is required."
}

The Timetable API defines error handling through HTTP status codes and a shared Error response object.

HTTP statusResponse schemaMeaning
400ErrorInvalid request
401ErrorAuthentication missing or invalid
403ErrorAuthenticated caller not allowed
404ErrorRequested resource not found
500ErrorUnexpected server error
FieldRequiredDescription
titleyesShort, human-readable summary of the problem type.
statusyesThe HTTP status code.
detailnoHuman-readable explanation specific to this occurrence of the problem.
{
"title": "Forbidden",
"status": 403,
"detail": "Access to the requested timetable resource is not allowed."
}

The Messages API defines error handling through HTTP status codes. Only one error response body is explicitly modeled in the specification.

HTTP statusResponse schemaMeaning
400none definedInvalid request
401none definedAuthentication missing or invalid
403none definedAccess forbidden
422ExternalMessageSendResponseDto with error: ErrorResponseDtoRequest understood but semantically invalid
500none definedUnexpected internal error

For the 422 error case, the response uses an ErrorResponseDto nested inside ExternalMessageSendResponseDto:

FieldDescription
messageHigh-level error message summarizing the issue.
detailsArray of detailed messages explaining specific issues.
{
"error": {
"message": "Validation Failed",
"details": [
"Subject must not be blank",
"At least one recipientUserUuid is required"
]
}
}

The OneRoster API defines error handling through HTTP status codes and a shared structured ErrorPayloads response body.

HTTP statusResponse schemaMeaning
400ErrorPayloadsRequest was invalid and cannot be served
401ErrorPayloadsRequest requires authorization
403ErrorPayloadsServer understood the request but refuses further action
404ErrorPayloadsNo resource exists behind the URI
429ErrorPayloadsToo many requests; retry later
500ErrorPayloadsInternal server error

ErrorPayloads is an array of ErrorPayload objects.

FieldDescription
errorCodeNumeric error code.
codeMajorHigh-level classification. Values: success, failure.
severitySeverity of the result. Values: status, warning, error.
codeMinorSpecific machine-readable classification. Values: full success, invalid_sort_field, invalid_selection_field, invalid data, invalid_filter_field, invalid_blank_selection_field, unauthorized, forbidden, unknown object, server_busy.
descriptionHuman-readable description of the error.
[
{
"errorCode": 4001,
"codeMajor": "failure",
"severity": "error",
"codeMinor": "invalid data",
"description": "The request contains invalid filter parameters."
}
]