DocumentationGET Bank List
SafeHaven Transfers API
GET
/safehaven/transfers/banksBank List
Bank List through this project environment’s SafeHaven account. Uses snake_case fields and NGN minor units. Requires transfers:read.
Use your sandbox environment to start. Understand error codes and payment statuses before handling a live payment.
Bank List
curl --request GET "https://api.veyqo.org/api/v1/safehaven/transfers/banks" \
--header "Authorization: Bearer $VEYQO_SECRET_KEY" \
--header "Accept: application/json"{
"success": true,
"data": []
}Illustrative examples. Replace IDs and environment variables with your own values. Keep secret keys on your server.
Headers
Authorizationstringrequired- Bearer <secret-key>. This key determines your project environment and must stay on your server.
Acceptstringoptional- application/json
Endpoint
GET https://api.veyqo.org/api/v1/safehaven/transfers/banks
Server secret key required. Scope: transfers:read. The key determines the project and environment; no project-selection header is accepted.
Response fields
[].namestringoptional- See the JSON example.
[].routing_keystringoptional- See the JSON example.
[].logo_imageJSONoptional- See the JSON example.
[].bank_codestringoptional- See the JSON example.
[].category_idstringoptional- See the JSON example.
[].nuban_codeJSONoptional- See the JSON example.
Errors and recovery
| Code | HTTP | Recovery | Retry policy |
|---|---|---|---|
| VALIDATION_FAILED | 422 | Read error.details when present, correct the named fields and retry only after correction. Validation messages may describe state/capability errors without field details. | No automatic retry. |
| INVALID_API_KEY | 401 | Use a current kc_test_ or kc_live_ secret key on /api/v1. Use a pk_test_ or pk_live_ publishable key only on browser checkout. | After fixing credentials. |
| INSUFFICIENT_PERMISSION | 403 | Grant the required scope or use a suitably scoped key. Dashboard organization roles and staff permissions are separate. | After permission changes. |
| RESOURCE_NOT_FOUND | 404 | Check the ID, project and environment. Do not guess another project’s IDs. An inactive payment link is also not-found. | No blind retry. |
| PROVIDER_NOT_CONNECTED | 422 | Connect a provider, choose the project default, or explicitly pass provider. An account shared with another project still needs its own assignment here. | After configuration changes. |
| PROVIDER_AUTHENTICATION_FAILED | 502 | The merchant must check/rotate the provider credentials in the dashboard. Do not expose those secrets to your application users. | After credential correction; reconcile existing payment first. |
| PROVIDER_REQUEST_FAILED | 422 | Read the safe message, inspect the payment’s failure details and correct the request or provider account. Never repeatedly retry a business rejection. | Only after resolving the cause. |
| PROVIDER_UNAVAILABLE | 503 | Check the existing payment and verify its state before starting another attempt. Retry safe reads with backoff; preserve operation identity for retried writes. | Conditional: reconcile unknown outcomes first. |
| RATE_LIMIT_EXCEEDED | 429 | Honor Retry-After, use bounded exponential backoff with jitter, and reduce concurrent requests. Read X-RateLimit headers. | Yes, after Retry-After; preserve write idempotency. |
| IDEMPOTENCY_KEY_REUSED | 409 | Reuse the exact original request to recover that operation, or use a new key only for a genuinely different operation. | Do not retry a changed body with that key. |
| IDEMPOTENCY_IN_PROGRESS | 409 | Wait briefly, retry with the same key and unchanged request, then reconcile by reference if the result remains uncertain. | Back off with jitter; preserve key/body. |