> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.io/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Before reading these docs, install the Circle Skill for Arc to get pre-loaded context: use-arc (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-arc/SKILL.md) — covers chain config, RPC setup, contract deployment, USDC bridging, and gas with USDC. In Claude Code: run /plugin marketplace add circlefin/skills then /plugin install circle-skills@circle. With Vercel Skills CLI: run npx skills add circlefin/skills.
> USDC is the gas token. Arc uses USDC for gas fees, not ETH. Configure gas payment in USDC when submitting transactions.
> Read EVM differences before writing Arc code. Arc targets the Osaka EVM baseline. Most contracts deploy unchanged, but several runtime behaviors diverge from Ethereum: USDC uses 18 decimals natively (not 6), the system emitter `0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE` logs all USDC Transfer events, the mempool enforces a 20 Gwei `maxFeePerGas` floor, blocklist reverts consume gas without a receipt, and `address(0)` sends revert rather than succeed. https://docs.arc.io/arc/references/evm-differences.md is the canonical reference for all Arc-specific runtime behaviors. Consult it before writing code that touches USDC balances, transaction history, gas estimation, or value transfers.
> Sub-second finality. Transactions are final in under 1 second. No need to wait for multiple block confirmations.
> Use App Kits for multichain payment and liquidity capabilities. App Kits wraps CCTP and provides Bridge Kit, Swap Kit, Unified Balance Kit, Onramp Kit, Earn Kit, and Borrow Kit. Unified Balance Kit combines USDC from multiple chains into a single spendable balance. Earn Kit integrates earn opportunities into your app. Borrow Kit lets users borrow USDC against cirBTC collateral on Arc.
> Use Arc Foundry for contract development. Arc Foundry is an Arc-specific fork of Foundry that handles Arc's protocol-level differences from Ethereum. It provides arc-forge, arc-cast, and arc-anvil. Install it before deploying contracts: https://docs.arc.io/arc/tutorials/install-arc-foundry.md.
> Arc is available on both Testnet and Mainnet. See https://docs.arc.io/arc/references/connect-to-arc.md for RPC endpoints and https://faucet.circle.com for testnet tokens.
> Always check Contract Addresses: https://docs.arc.io/arc/references/contract-addresses.md
> Building beyond Arc? Circle offers skills for the full platform: use-usdc (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-usdc/SKILL.md), use-circle-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-circle-wallets/SKILL.md), use-developer-controlled-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-developer-controlled-wallets/SKILL.md), use-user-controlled-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-user-controlled-wallets/SKILL.md), use-modular-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-modular-wallets/SKILL.md), use-gateway (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-gateway/SKILL.md), use-smart-contract-platform (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-smart-contract-platform/SKILL.md). Full Circle developer docs: https://developers.circle.com/llms.txt.

# Onramp error handling

> Catch and classify Onramp errors using KitError fields, see common error codes, and understand how the session route handler maps errors to HTTP status codes.

Every error the App Kit SDK throws for Onramp is a `KitError`, exported from
`@circle-fin/app-kit`. Its structured fields let you branch on the failure type
instead of parsing message strings. For a full integration walkthrough, see the
[embed widget quickstart](/app-kit/quickstarts/onramp-embed-widget).

## `KitError` fields

| Field | Description |
| - | - |
| `type` | Classifies the failure. One of `INPUT`, `NETWORK`, `SERVICE`, `RATE_LIMIT`, `RPC`, or `UNKNOWN`. |
| `recoverability` | Indicates whether to retry. One of `RETRYABLE`, `RESUMABLE`, or `FATAL`. |
| `name` | Stable identifier for exact matching, logging, and telemetry. |
| `code` | Numeric sub-classification in a `name`. Stable identifier for telemetry. |
| `message` | Human-readable diagnostic. Not suitable for end-user display without review. |
| `cause` | The underlying error, if one was wrapped. |

Prefer `type` and `recoverability` for control flow. They are the stable,
forward-compatible contract. Use `name` and `code` only for exact matching,
logging, and telemetry.

## Error handling

Catch a `KitError` and branch on `type` and `recoverability` to decide how to
recover:

```typescript TypeScript theme={null}
import { KitError } from "@circle-fin/app-kit";

try {
  const session = await kit.onramp.fetchSession({ url, body });
  kit.onramp.mountIframe({ session, container });
} catch (err) {
  if (err instanceof KitError) {
    if (err.recoverability === "RETRYABLE") {
      return scheduleRetry();
    }
    if (err.type === "INPUT") {
      return showValidationError(err.message);
    }
    if (err.type === "RATE_LIMIT") {
      return showRateLimitToast();
    }
  }
  throw err;
}
```

## Common error codes

| Code | Name | Type | When it fires |
| - | - | - | - |
| `1907` | `INPUT_INVALID_API_KEY` | `INPUT` | API key is missing, invalid, or unauthorized (401 or 403). |
| `1910` | `INPUT_WIDGET_URL_ORIGIN_MISMATCH` | `INPUT` | `mountIframe` or `openWindow` called with a `widgetBaseUrl` that doesn't match the server's. |
| `1914` | `INPUT_NO_WINDOW` | `INPUT` | The client kit was used in a non-browser environment. Run client code in the browser, or pass a `window`. |
| `8923` | `SERVICE_SESSION_ENDPOINT_REJECTED` | `SERVICE` | Your session route returned a non-2xx response. Check auth on your route or the request body. |

## HTTP status code mapping

`createSessionRouteHandler` maps thrown errors to HTTP status codes
automatically:

| `type` | HTTP status | Meaning |
| - | :-: | - |
| `INPUT` | 400 | The request body failed validation. |
| `RATE_LIMIT` | 429 | Too many requests. Retry after a backoff. |
| `NETWORK` | 504 | Upstream connection failed or timed out. |
| `SERVICE` | 502 | Upstream service returned an error. |
| `RPC` | 502 | Upstream RPC call failed. |
| `UNKNOWN` | 500 | Unclassified error. |

The handler also returns:

* `405 Method Not Allowed` for any method other than `POST`.
* `400 Bad Request` if the body cannot be parsed as JSON.
* `401 Unauthorized` if your `authorize` callback returns `false`.

Upstream response bodies are never echoed into the response. Only the status
code and length of the upstream response are kept on `KitError.cause` for
diagnostic purposes.

## Error sources

| Source | Throws when | `type` |
| - | - | - |
| `new AppKit()`, `createAppServerKit()` | Constructor options are missing or invalid. | `INPUT` |
| `kit.onramp.mountIframe()` | The session has expired or is malformed, or the container is missing. | `INPUT` |
| `kit.onramp.openWindow()` | The session has expired or is malformed. | `INPUT` |
| `server.onramp.createSession()` | Input is invalid, the upstream API rejects the request, or the network fails. | `INPUT`, `NETWORK`, `SERVICE`, `RATE_LIMIT` |
| `kit.onramp.fetchSession()` | Your session route returns a non-2xx response, or the body can't be parsed. | `INPUT`, `NETWORK`, `SERVICE` |

Runtime widget errors are surfaced through the `INITIALIZATION_ERROR` event
rather than thrown. See
[Handle lifecycle events](/app-kit/tutorials/onramp/handle-lifecycle-events).