Skip to main content
Yapily uses two error response formats. Check which format your product uses below.

Which Error Format Does My Product Use?

Products using enhanced error format with structured issue codes:
  • Hosted Pages
  • Data Plus
  • Webhooks
  • User & Application Beneficiaries
  • VRP (only for payload validation)
  • Bulk Payment (only for payload validation)
Scroll down to the Enhanced Error Format Documentation section for details.

Enhanced Error Format Documentation

Used by: Hosted Pages, Data Plus, Webhooks, User & Application Beneficiaries, VRP (payload validation), Bulk Payment (payload validation)
This format provides detailed error information with structured issue codes. For other operations, see HTTP Status Code Format Documentation.

Introduction

When you make an API call to Yapily and there is an error, you will receive an error response including error codes and message fields to help you diagnose and solve the error. We recommend building your error handling logic around the Error Codes and Message properties in the response, as these provide the most specific information about the underlying issue.

Response Structure

When receiving an error response, it is important to note that there might be multiple error codes included. To effectively troubleshoot the problem, you need to consider all of these error codes.
When an error occurs, you’ll receive a response with an error object containing an issues array:
If you need to contact support, we advise you share the error response with us, or if not possible include the tracingId and the error codes so we can identify your request and trace the origin of the issue.

Error Code Structure

The error codes are structured as follows:
  • First 2 digits: Represent the group of the error
  • Last 3 digits: Represent the specific error within the group

Error Catalogue

Below is a list of possible error issue codes, along with additional information about how to resolve them.

Unknown Error

We will be sending this error if we encountered an error we haven’t seen yet and does not have a handler on our side. If you see this error please contact support.

10xxx Pre-Flight Checks

This error group represents issues that occur either before payload and header validation, or during third-party calls that use the data from the original request.

11xxx Payload Validation

12xxx Request Header Validation

13xxx Authorisation Process

14xxx Resource Operation

15xxx Payment Process

16xxx Transactions Retrieval Process

17xxx Institution Interaction

18xxx Query Parameters

20xxx Webhook Validation

21xxx VRP Mandate Validation


HTTP Status Code Format Documentation

Used by: Financial Data (Accounts, Transactions, Balances), Single Payments, Bulk Payments, Authorisations, Consents, Institutions & Users, Variable Recurring Payments (VRPs)

Introduction

After sending an API request, you may receive a response back including an error object. You should build logic to account for any API errors that a request or the system may return. You may also receive an authorisation error after the end user’s redirection to the bank. You should log the query parameters returned from the redirect to understand any failures that occur.

Error Response Fields

All errors are returned with the same structure. The response object contains the following fields for 4XX errors:
500 Internal Server Errors return a simplified structure containing only the message field and tracingId:
Example 4XX error response:
If you need to contact support, include the tracingId so we can identify your request.

HTTP Response Codes

Yapily uses standard HTTP response codes to indicate the success or failure of an API request.

Authorisation Errors

Authorisation errors can occur when the user is redirected to the institution to provide their consent. If the user doesn’t provide their consent or there is an issue with the institution, the failure response is returned as query parameters. We recommend you log the query parameters received on your callback URL or redirect URL for all requests so you have access to the information explaining what has occurred. For more information see:

Handling Missing Callbacks

Callbacks may not reach your application due to network issues, browser restrictions, or bank-side errors. When this happens, users can become stuck in incomplete flows. To prevent this, poll the consent or payment status endpoint to check if the authorisation completed successfully. Implementation Steps:
  1. Set a timeout: Wait 10-15 minutes after redirecting the user to the bank
  2. Start polling: If no callback is received, poll at increasing intervals: 1s, 2s, 3s, 5s, 8s, 13s, 21s, 34s. Stop after 8 attempts (~1.5 minutes total).
  3. Handle the result based on the status returned:
    • AUTHORIZED - Continue your flow
    • REJECTED - Show error message to user
    • AWAITING_AUTHORIZATION - User may still be completing authorisation on the bank screen or app
    • FAILED - Show error details
Example Implementation:
If Using Yapily Connect (https://auth.yapily.com/): Contact Yapily Support with your consent or payment ID if you receive no callback. We log all redirects to our URL and can investigate. If Using Your Own Redirect URL: You must implement the polling strategy above. Yapily cannot log redirects to your URL, so ensure your endpoint has comprehensive logging to diagnose failures.

When to Contact Support

If you encounter errors that you cannot resolve:
  1. Collect the error details:
    • tracingId from the error response
    • Full error response body
    • Request details (endpoint, parameters)
  2. Review the documentation:
    • Check the error code catalog above
    • Verify your request format matches our API Reference
    • Review product-specific documentation
  3. Contact support:
    • Visit our Support page
    • Include the tracingId in your message
    • Provide context about what you’re trying to accomplish
Our support team can help investigate issues and provide guidance on resolving errors.