Routing API v7 Developer's Guide

Error Data Types

Error details are transferred to the client using a generic error structure, which is returned instead of the actual response structure.

Schema location (Source)
XSD Version 1.0
Figure 1. RoutingServiceErrorType This image shows a graphical representation of the routing service error type.

The error type defines the following attributes:


Errors are categorized into one of the following groups:

  • ApplicationError

    Errors that are thrown since the business logic has detected some error

  • SystemError

    Errors that are thrown due to technical reasons

  • PermissionError

    Errors that are thrown to reject incoming requests due to invalid credentials or missing entitlements

@subtype Defined name of the concrete error, such as "InvalidInputData" or "ExceededUsageLimit".
Details Clear text error message
RequestId Arbitrary value to trace back the request. This value is copied from the request which caused the error.
AdditionalData Generic container to include structured details regarding the error. Each concrete error sub type defines the semantics of the values in the container.
MetaInfo RouteResponseMetaInfoType

Provides details about the request itself, such as the time at which it was processed, a request id, or the map version on which the calculation was based.

Errors are returned in the same format (XML, JSON, JSONP) as the expected response.

The error type name is mapped to the ServiceError.type attribute. Services may define their own, more specific errors based on these three error types. The name of the more specific error type is then mapped to the ServiceError.subtype attribute.

However, the basic error types may also be used for concrete errors if there is no sub type that better fits the error situation. In that case, the ServiceError.subtype attribute is omitted.

The usage of the ServiceError.AdditionalData element is not defined for the basic error types. Error sub types may define their own values.