Errors

At Qonto, we adhere to industry best practices for error handling, following the JSON:API error object format to provide clear, consistent, and actionable error responses for all API interactions. We use conventional HTTP response codes to communicate the success or failure of an API request. In general:

2xx codes indicate a successful request.
4xx codes represent errors where the request could not be processed due to issues with the provided information (e.g., missing parameters, invalid data, etc.).
5xx codes indicate server-side errors at Qonto (these are rare).

Every error response contains an errors array. Each error object includes:

code: A machine-readable code identifying the error, such as not_in_list.
detail: A more detailed human-readable description of the error, useful for debugging or for the client to understand the exact issue.
source.pointer (optional): The property in the request body that caused the error. This is helpful for pointing directly to the faulty part of the request body.

Error Response Format

On the Onboarding Partners API, the error object declared in the specification includes the following fields:

{
  "errors": [
    {
      "code": "string",
      "detail": "string",
      "source": {
        "pointer": "string"
      }
    }
  ]
}

code and detail are always present; source is optional. When reporting a failing request, see Support for what to include.

Introduction

Registrations

Files

Partner events

Webhooks

Error Response Format

​Error Response Format

Error Response Format