DOCUMENTATION
Guides
Recipient login

Akoya API error cases

Validate all errors triggered by Akoya API. This section validates data calls. Tokens are tested in the prior section.

Suggest Edits

📘

Notes:

Errors return as standardized FDX error codes. See Errors.

Data calls can be validated against the provider-specific Mikomo users and sample responses for payload structure and actual data elements.

Test caseTask(s)Expected result(s)
Try an invalid API call.Use /accounts-info endpoint with incorrect parameter detail instead of details.HTTP 400: Bad Request

Error payload:
{
   "code": 401,
   "message": "Invalid input"
}
Ensure that a recipient can’t access provider data without a subscription.Use /accounts-info endpoint with an incorrect id_token, even a valid token with another provider.HTTP 401: Unauthorized

Error payload:
{
   "code": 602,
   "message": "Customer not authorized"
}
Try the token of another user from the same provider.Have two valid end-user tokens.

Use the id_token for user 1 in an /accounts-info call with the query parameter accountIds set for an account for user 2.		HTTP 404: Not Found

Error payload:
{
   "code": 701,
   "message": "Account not found"
}
Try to get transactions without specifying the account.Use /transactions endpoint without the accountId path variable.HTTP 404: Not Found

Error payload:
{
   "code": 701,
   "message": "Account not found"
}
Try to get accounts or transactions with incorrect provider.Use /transactions endpoint without the providerId path variable.HTTP 400: Bad Request

Error payload:
{
   "code": 401,
   "message": "Invalid Input"
}
Try start and/or end dates that are not in the ISO8601 format.Use /transactions endpoint with startTime and endTime parameters with a string that is not ISO 8601 date format in UTC time zone.HTTP 400: Bad Request

Error payload:
{
   "code": 702,
   "message": "Invalid start or end date"
}
Try invalid dates.Use a date that is prior to available transaction history.HTTP 200: OK

Error payload:
{
   "transactions": []
}

Some errors are difficult to replicate. For instance, there is no way for you to revoke an end-user’s consent via their bank’s app or website to test the errors that would result in your app. In these cases, we’ve made Mikomo users that when used, will supply certain error codes and messages. One such user is mikomo_601. When data is requested for this user, the result will always be a 601 error. See: Mikomo Error testing.

To test with these Mikomo users, go through the consent flow as usual to obtain an ID token. Then, any data call will result in the errors listed below.

Test caseTask(s)Expected result(s)
Try using a revoked ID token.1. Use error test case mikomo_601 to mimic this type of error.

2. Use error test case mikomo_602 to mimic this type of error.		1. HTTP 404: Not Found

Error payload:
{
   "code": 601,
   "message": "Customer not found"
}

2. HTTP 401: Unauthorized

Error payload:
{
   "code": 602,
   "message": "Customer not authorized"
}
Internal service errorUse error test case mikomo_500 to mimic this type of error.HTTP 500: Internal Server Error

Error payload:
{
   "code": 500,
   "message": "Internal server error"
}
Subsystem unavailableUse error test case mikomo_501 to mimic this type of error.HTTP 500: Internal Server Error

Error payload:
{
   "code": 501,
   "message": "Subsystem unavailable"
}

Need help?

Check out our Developer Community, or visit the Support Center in the Data Recipient Hub.

Looking for provider nuance documentation?

All provider nuance documentation is available in the Data providers section in the Data Recipient Hub.

Still stuck?

For all production issues, submit a support ticket through the Data Recipient Hub. Our support team is standing by 24/7. Questions and non-production issues will be answered during business hours.

Updated 4 months ago