Error Handling

What error codes are there and how to handle errors.

Success and Error codes

Each API request will return a response. A successful request will typically return a 200 OK status code along with any requested data. Errors or issues with your request will return different status codes (e.g., 400 Bad Request, 401 Unauthorized) and an error message explaining what went wrong.

Success Codes



OK - The request has succeeded.


Created - The request has been fulfilled and has resulted in one or more new resources being created.


Accepted - The request has been accepted for processing, but the processing has not been completed.


No Content - The server successfully processed the request, but is not returning any content.

Error codes



Bad Request - The server cannot process the request due to a client error (e.g., malformed request syntax).


Unauthorised - The request lacks valid authentication credentials for the target resource.


Not Found - The server can't find the requested resource.


Internal Server Error - The server encountered an unexpected condition that prevented it from fulfilling the request.

Error Message Standard

Error handling for all API methods must adhere to the RFC7807 standard, ensuring standardized and informative error responses for clients. Please see

Please see below of a standard example.

   "title":"Your request parameter didn't validate.",
         "Mandate with the reference already exists."
               "Individual with the reference already exists."
               "Individual with the reference already exists."

RFC7807: Problem Details for HTTP APIs

RFC7807 is a standard for providing machine-readable error details in HTTP API responses. It was designed to offer a consistent way for servers to return error information in a structured format, making it easier for clients to understand and react to issues.

Key Features of RFC7807

  1. Structured Error Responses: RFC7807 proposes a standard format for error messages, including fields like type, title, status, detail, and instance. This structure ensures that error information is conveyed in a predictable and easily parsable manner.

  2. Extensibility: The standard allows for custom properties to be added to the error response. This means that while there's a common base of error information, additional details specific to an application or domain can be included.

  3. Machine-Readable and Human-Friendly: The error responses are designed to be both machine-readable (easy for software to parse) and human-friendly (easy for developers to understand and debug).

  4. Uniform Handling of Errors Across APIs: By adhering to a standard, it simplifies the client's task in handling errors because the format remains consistent across different APIs.

Last updated