Skip to main content

Error Handling

The FYATU CaaS API v3.20 uses a unified response envelope for every response — success and error alike. The top-level shape is always the same; only the fields that are populated change.

Response Envelope

Success — single resource

Success — paginated list

Error

Validation error (multiple fields)

When a request fails validation, the error object includes a fields array:

Envelope Fields

Use error.code in your switch statements for programmatic handling. Use message for displaying to end-users. Use meta.requestId when contacting support.

HTTP Status Codes

Error Code Catalogue

Authentication and Authorization

Validation

General

Program Errors

Cardholder Errors

Card Errors

Balance Errors

Withdrawal Errors

Webhook Errors

Retry Strategy

Only 429 and 5xx errors should be retried. 4xx errors (except 429) indicate a problem with the request — retrying without fixing it will not succeed.
Node.js — retry helper
Python — retry helper

Error Handling Patterns

Inspect error.code for programmatic handling

Node.js
Python

Using meta.requestId for Support

Every response — success or error — includes a meta.requestId. This ID uniquely identifies the request in FYATU’s systems and allows the support team to trace exactly what happened. When contacting support about an unexpected error, always include:
  1. The meta.requestId from the failing response
  2. The HTTP status code
  3. The error.code value

Common Errors by Scenario

Issuing a card — cardholder KYC not yet approved

Error
Fix: Subscribe to the CARDHOLDER_KYC_APPROVED webhook. Issue the card only after the event fires.

Funding a card with insufficient program balance

Error
Fix: Deposit funds to your program via the CaaS portal or the deposit workflow, then retry.

Terminating a card with pending transactions

Error
Fix: Wait for pending authorizations to clear (typically 24–72 hours), then retry.

Missing termination confirmation

Error
Fix: Include "confirm": "TERMINATE_CARD" in the request body.