Skip to content

Error response format

All errors from the ev.energy API use standard HTTP status codes and return bodies in the standard "Problem Details" format described by RFC 9547.

HTTP status codes

| Status code | Meaning | | ---------------------- ------------------------------------------------------------------------------------------- | | 400 Bad Request | The request could not be parsed or failed validation. | | 401 Unauthorized | The request must include a valid authorization token as described here. | | 403 Forbidden | The authorization token for this request does not have permission to access the resource. | | 404 Not Found | The resource does not exist. | | 405 Method Not Allowed | The endpoint does not support that method, check the API reference. | | 429 Too Many Requests | The request exceeded rate limits, see documentation. |

Problem Details

A full description of the format can be found in RFC 9547. For straightforward errors that are clearly covered by an HTTP status code, such as 404 Not Found, the server will return a response like this:

{
  "title": "Not found",
  "status": 404,
  "detail": "Resource does not exist or cannot be accessed.",
}

The "type" property is omitted because the status code is sufficient. For more ambiguous errors, primarily 400 Bad Request, more detail will be provided:

{
  "title": "Invalid pagination parameter",
  "status": 400,
  "detail": "Invalid value for pagination parameter: page_size",
  "type": "https://api.ev.energy/v2/problems/pagination-paramaters/"
}

The "type" property serves two purposes:

  • It is a consistent identifier for all problems of this type, which can clients can use to activate problem-specific handling.
  • It is a link to the relevant documentation to aid in resolving the problem.

If the error relates to a particular resource, an "instance" property will be included, containing the URL of that resource.

Field level errors

Some error responses, mostly commonly 400 Bad Request responses on POST, PUT or PATCH requests, return structured, field-specific error details. For example:

{
  "title": "Request failed validation.",
  "detail": "Error on fields: user, trim",
  "status": 400,
  "type": "http://testserver/v2/problems/validation-failed-create-vehicle/",
  "field_errors": {
    "user": ["This field is required."],
    "trim": ["Invalid hyperlink - Object does not exist."]
  }
}

Each entry in the field_errors object maps directly to a field in the body of the request or response, and contains one or more strings detailing the validation error. This can be used to provide more contextual error output to users.