Skip to main content
Branch on the class, never on the status code. The API reports the same missing-key cause as 401 on one endpoint and 400 on another, so a status-based branch is wrong somewhere by construction.

The classes

Every one extends BrickkenError, which carries .code, and — where the API supplied them — .status and .body.

Errors that carry recoverable state

Three of them exist so a failure does not cost you the work already done.

BroadcastConfirmationError

The transaction is already on chain. Re-signing and re-broadcasting would be wrong. Resume only the confirmation step:

CreditsExhaustedError

Each Dapp write method carries its own credit balance, so one method can run out while others still work. .method names the one that did.

Any error with .payment

A failure that happened after an x402 payment was authorized sets .payment on the error, so the charge can be reconciled against what actually ran.

Retries

Retries use jittered exponential backoff. The defaults are three attempts with a 500 ms base delay, and are configurable:
The paid-send rule is the important one: a send whose payment was authorized is never retried automatically, because a retry could be a second charge. If it fails, the error carries .payment and the decision is yours.

Payments

The controls that stop a payment before it happens.