# Errors Generated from `packages/contracts-api/errors.ts`'s `ERROR_CODES` by `scripts/openapi/normalize.mjs`, as part of `pnpm run api:contract` — never hand-edited. Every error envelope's `doc_url` (see [Conventions § Errors](/conventions#errors)) points at this page, one anchor per code a `/v1` caller can actually receive: `https://docs.swaps.app/errors#code`. A code, once shipped, is additive-only — never renamed or removed. The status shown per code is its `type`'s canonical status, not always the literal status a legacy pre-`/v1` handler answers for that same code today. A code registered only to satisfy an internal invariant but never returned to a caller is listed under its type's "Internal label, never returned" section instead. | `type` | HTTP | Agent recovery | |---|---|---| | `invalid_request` | 400 / 405 / 413 / 422 | Fix the argument and retry. | | `authentication_error` | 401 | Re-authorize; do not retry as-is. | | `permission_error` | 403 | Wrong actor or scope — call as the right one. | | `not_found` | 404 | The id is not visible to this caller — also the cross-account answer. | | `conflict` | 409 | State moved — re-read, then decide. | | `idempotency_error` | 409 | Same key, different body. | | `rate_limit_error` | 429 | Back off; `Retry-After` is set. | | `capability_unavailable` | 409 | Do **not** retry — this corridor or product cannot serve it. | | `temporarily_unavailable` | 503 | A kill switch is thrown, or a dependency is out; retry after `Retry-After`. | | `quota_exhausted` | 402 | An allowance is spent — backing off does not restore it; upgrade or buy credits. | | `provider_error` | 502 / 503 | Upstream failed; retry only where stated. | | `api_error` | 500 | Ours — open a support ticket with the request id. | ## Terms acceptance Legal acceptance is disabled until a published revision and action schedule are explicitly activated. For a covered new live action, `409 terms_acceptance_required` carries `details.revision` and `details.action`. Ask the person using Swaps to review the terms; only the account owner can accept on behalf of an account. An API key, MCP tool or agent cannot create a receipt. Privacy notices, optional cookies, provider agreements and payment authorization remain separate. The first coverage is new payment links/activation, subscriptions/resumption, payouts, payroll runs, wallet send/deposit intents and orders. This is not a claim that every legacy or guest route is gated. Reads, cancellations, recovery and completed idempotent responses retain their existing paths. Test mode does not accept live terms. A legal refusal occurs before the new operation's handler and releases its new idempotency reservation. After acceptance, retry the same unchanged request with the same key. `503 legal_acceptance_unavailable` means verification failed, not that acceptance is waived; respect `Retry-After`. For any ambiguous operation result, reconcile the object or events before considering a new key. ## Type `invalid_request` ### `account_holder_unavailable` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `allowed_rails_invalid_for_settlement` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `amount_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `beneficiary_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `bridge_execute_rejected` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `confirmation_required` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `crypto_only_currency_not_usd` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `deposit_amount_below_minimum` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `destination_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `destination_rail_indeterminate` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `destination_rail_keyless` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `fiat_rail_mismatch` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `funding_method_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `iban_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `idempotency_key_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `idempotency_key_required` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `individual_amount_above_limit` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `individual_amount_unverifiable` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `individual_rail_unavailable` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `invalid_last_event_id` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `invalid_request` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `item_currency_mismatch` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `item_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `items_required` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `items_too_many` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `link_expired` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `link_not_payable` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `livemode_boundary` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `method_not_allowed` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: agent_api, api_v1 ### `mixed_currency_not_supported` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `mode_mismatch` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `no_payable_rail` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `owner_name_mismatch` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `p2p_amount_above_limit` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `pay_period_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `payer_type_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links, payouts ### `payer_type_mismatch` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payload_too_large` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `payout_refund_address_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_refund_address_not_allowed` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_refund_address_unsupported` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_source_chain_missing` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payroll_item_limit_exceeded` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `payroll_run_limit_exceeded` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `rail_not_allowed` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `refund_address_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `refund_address_required` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `settlement_account_holder_missing` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `settlement_conflicts_with_destination` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `settlement_destination_provider_refused` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `settlement_destination_required` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `settlement_details_incomplete` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `settlement_intent_conflict` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `settlement_rail_unsupported` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `source_tx_failed_onchain` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `source_tx_mismatch` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `source_tx_wrong_sender` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `stablecoin_invalid` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `tempo_settlement_currency_not_usd` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `tempo_via_bridge_not_enabled` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `travel_rule_counterparty_required` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `travel_rule_originator_incomplete` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `travel_rule_proof_required` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `unsupported_route` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `unsupported_version` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `wallet_network_not_supported` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `wallet_not_provisioned` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `webhook_url_not_allowed` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `webhook_url_not_https` 400 / 405 / 413 / 422 — `invalid_request`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ## Type `authentication_error` ### `authentication_error` 401 — `authentication_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `invalid_api_key` 401 — `authentication_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: agent_api, api_v1 ## Type `permission_error` ### `account_inactive` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `bridge_customer_missing` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `bridge_wallet_address_unavailable` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `bridge_wallet_missing` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `deposits_restricted` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `destination_blocked` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `eea_kyc_required` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `ip_not_allowed` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: agent_api, api_v1 ### `kyc_not_approved` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `missing_address_data` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `no_base_endorsement` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `no_settlement_endorsement` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `payer_bridge_customer_missing` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payer_customer_missing` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `payroll_verified_customer_required` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `permission_error` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, core ### `requirements_outstanding` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `role_denied` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `scope_denied` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: agent_api, api_v1 ### `tos_not_accepted` 403 — `permission_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ## Type `not_found` ### `not_found` 404 — `not_found`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 #### Internal label, never returned Registered to satisfy the "every thrown code is in the registry" invariant, but always remapped or folded to a different code before a `/v1` response leaves the boundary — never appears on the wire as this code. ### `external_account_not_found` ### `payout_receipt_not_ready` ## Type `conflict` ### `account_already_exists` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `allowed_rails_invalid_for_currency` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `cancel_unavailable` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `checkout_expired` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `conflict` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, core ### `conversion_source_tx_already_recorded` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `customer_already_exists` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `customer_mapping_stale` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `customer_type_conflict` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `funding_method_locked` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `funding_not_verified` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `holder_selection_required` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `legacy_wallet_read_only` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `no_pending_destination` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `payment_in_progress` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `payment_link_pay_in` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `payout_funding_instructions_not_ready` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `payout_not_fundable` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_refund_address_locked` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_source_chain_locked` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_transfer_missing` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payroll_run_funding_instructions_not_ready` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `pending_destination_changed` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `provider_adapter_disabled` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `rail_not_ready` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `receipt_not_available` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `recipient_destination_not_ready` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `requote_required` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `reusable_bridge_template` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `run_has_no_rows` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payroll ### `send_intent_payout_closed` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `source_tx_already_recorded` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `source_tx_not_yet_confirmed` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `wallet_already_exists` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `wallet_balance_short` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `wallet_funding_claimed` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts, wallet ### `wallet_funding_in_flight` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `wallet_funding_pending` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `wallet_funding_unavailable` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `wallet_not_found` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `webhook_endpoint_disabled` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `webhook_endpoint_limit_exceeded` 409 — `conflict`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ## Type `idempotency_error` ### `idempotency_error` 409 — `idempotency_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `idempotency_failed` 409 — `idempotency_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `idempotency_in_progress` 409 — `idempotency_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ## Type `rate_limit_error` ### `rate_limit_exceeded` 429 — `rate_limit_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: agent_api, api_v1, payment_links ## Type `capability_unavailable` ### `account_email_unavailable` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `accounts_not_enabled` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `capability_unavailable` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, core ### `conversion_no_liquidity` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `conversion_unavailable_single_token_network` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `destination_rail_unsupported` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `external_account_address_unavailable` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `external_account_currency_mismatch` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `external_account_rail_mismatch` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `network_not_supported` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `offramp_quote_unpriceable` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `offramp_route_unavailable` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `provider_not_supported` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `provider_paused` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `terms_acceptance_required` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `virtual_account_holder_not_verified` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `virtual_account_requirements_outstanding` 409 — `capability_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ## Type `temporarily_unavailable` ### `beneficiary_commit_pending` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `crypto_relay_flag_read_failed` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `customer_status_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `destination_check_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `destination_risk_unverifiable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links, payouts, payroll ### `eligibility_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `legal_acceptance_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `mail_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `named_payout_config_commit_pending` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payer_type_unverifiable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_cancel_commit_pending` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_cancel_retryable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_funding_commit_pending` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_fx_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_mark_sent_failed` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_quote_refresh_failed` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_replacement_failed` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_source_quote_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `payout_transfer_recovery_pending` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `rail_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `relay_route_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `source_tx_record_failed` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `summary_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `temporarily_unavailable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, core ### `wallet_funding_cancel_failed` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ### `wallet_state_unverifiable` 503 — `temporarily_unavailable`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payouts ## Type `quota_exhausted` ### `quota_exhausted` 402 — `quota_exhausted`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, core ## Type `provider_error` ### `collection_va_payee_name_missing` 502 / 503 — `provider_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `conversion_no_steps` 502 / 503 — `provider_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `live_provider_blocked` 502 / 503 — `provider_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `provider_instruction_invalid` 502 / 503 — `provider_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `relay_quote_failed` 502 / 503 — `provider_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ### `relay_quote_shortfall` 502 / 503 — `provider_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, payment_links ### `send_intent_no_steps` 502 / 503 — `provider_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1 ### `test_mode_unsupported` 502 / 503 — `provider_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: api_v1, wallet ## Type `api_error` ### `internal_error` 500 — `api_error`'s canonical status (RESOURCE-MODEL §0.7, not always the literal status a pre-`/v1` handler answers) · seen on: agent_api, api_v1 #### Internal label, never returned Registered to satisfy the "every thrown code is in the registry" invariant, but always remapped or folded to a different code before a `/v1` response leaves the boundary — never appears on the wire as this code. ### `run_item_totals_failed` ### `run_items_list_truncated`