Skip to main content
Circle Mint surfaces errors in two shapes: synchronous responses to API calls, and asynchronous status transitions on resources. The tables below catalog every code, organized by product. When an endpoint returns a generic code: -1 with a message of Something went wrong, treat it as the transient fallback and retry with backoff. For general errors that can be returned by any Circle API, see API errors.

Error response shape

Every synchronous error returns an HTTP status code plus a JSON body with a numeric code and a human-readable message. Validation errors include an extended errors[] array with one entry per offending field.
Each entry in errors[] carries an error name that you can branch on programmatically:

Synchronous and asynchronous errors

Circle Mint surfaces errors in two distinct shapes depending on when the problem is detected. Use these categories to decide how your integration should respond to a given error.

Risk evaluation reason codes

When Circle’s risk engine acts on a transaction, the affected resource (a payment, payout, or transfer) carries a riskEvaluation object alongside its errorCode. This object explains why the risk service reached its decision:
  • decision: the risk outcome, one of approved, denied, or review.
  • reason: a numeric reason code, returned as a string such as "3000", that identifies the specific reason for the decision.
Every reason code belongs to one of the following categories. The category tells you the source and nature of the block, and the code range narrows it to a specific reason. The following table lists the individual reason codes in each category.

Common errors

These codes can appear on any Circle Mint endpoint.

Core API errors

These codes cover the core money-movement endpoints: payments, payouts, transfers, and blockchain address management.

Stablecoin Payins errors

Most Stablecoin Payins asynchronous failures surface via the payments webhook and the paymentIntent lifecycle rather than through discrete error codes. The synchronous codes below cover checkout-session validation. For asynchronous failure events on payment intents and payments, see Webhook notifications.

Stablecoin Payouts errors

Stablecoin Payouts errors have two sources. Synchronous validation covers Travel Rule fields and Address Book entity validation. After submission, the payout entity itself can transition to failed with an errorCode that describes why.

Synchronous validation

For full Travel Rule context, see Travel rule compliance.

Asynchronous entity errors

When riskEvaluation.reason is 3220, the denial is a Travel Rule violation. Review your originator identities, beneficiary identity, VASP ID, and purposeOfTransfer, then resubmit with a new idempotencyKey. See Travel Rule Compliance. For the full list of riskEvaluation.reason values, see Risk evaluation reason codes.

Credit errors

The Credit API’s draw, fee, and repayment endpoints surface validation failures via a top-level validationErrors array on the credit line. When validationErrors is non-empty, draw and repayment endpoints return HTTP 400 until the listed conditions clear. Calling POST /v1/credit/cryptoRepayment against a Settlement Advance credit line returns HTTP 400—crypto repayment is only supported on Line of Credit lines. See the Credit API concept for product differences.

Institutional Distribution errors

These responses surface when you create or manage external entities through the Institutional API.

Custody balance errors

These codes apply to daily user balance reporting for custody accounts.

Transfer entity errors

These errorCode values appear on a transfer resource after it transitions to failed.