Yapily uses two error response formats. Check which format your product uses below.
Which Error Format Does My Product Use?
- Enhanced Error Format
- HTTP Status Code Format
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)
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 theError 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.
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
19xxx Consent Processing
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: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:- Set a timeout: Wait 10-15 minutes after redirecting the user to the bank
- 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).
- Handle the result based on the status returned:
AUTHORIZED- Continue your flowREJECTED- Show error message to userAWAITING_AUTHORIZATION- User may still be completing authorisation on the bank screen or appFAILED- Show error details
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:-
Collect the error details:
tracingIdfrom the error response- Full error response body
- Request details (endpoint, parameters)
-
Review the documentation:
- Check the error code catalog above
- Verify your request format matches our API Reference
- Review product-specific documentation
-
Contact support:
- Visit our Support page
- Include the
tracingIdin your message - Provide context about what you’re trying to accomplish