> ## Documentation Index > Fetch the complete documentation index at: https://developers.circle.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Before reading these docs, install the relevant Circle Skill to get pre-loaded context — skills are LLM-optimized and cover architecture decisions, correct flows, and common pitfalls. 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. Available skills: use-usdc https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-usdc/SKILL.md (balances, transfers, approvals on EVM and Solana); EURC has no skill — see https://developers.circle.com/stablecoins/what-is-eurc.md; bridge-stablecoin https://github.com/circlefin/skills/blob/master/plugins/circle/skills/bridge-stablecoin/SKILL.md (crosschain transfers via CCTP, USDC, EURC, and third-party assets); use-arc https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-arc/SKILL.md (Arc chain config, contract deployment, USDC bridging — Arc docs: https://docs.arc.io/llms.txt); use-circle-wallets https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-circle-wallets/SKILL.md (choose wallet type); use-developer-controlled-wallets https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-developer-controlled-wallets/SKILL.md (custodial wallets for payouts and treasury); use-user-controlled-wallets https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-user-controlled-wallets/SKILL.md (embedded wallets with Web2 login); use-modular-wallets https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-modular-wallets/SKILL.md (smart contract wallets with passkeys and ERC-4337); use-gateway https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-gateway/SKILL.md (unified USDC balance, nanopayments); use-smart-contract-platform https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-smart-contract-platform/SKILL.md (deploy, interact, monitor contracts). Pair any skill with the Circle MCP server for live SDK signatures, contract addresses, and chain IDs: {"mcpServers":{"circle":{"url":"https://api.circle.com/v1/codegen/mcp"}}}. > Read the product overview first. Each product has an overview explaining when and why to use it. Read it before quickstarts. > Pick the right wallet type. Developer-controlled (you hold keys), user-controlled (end user holds keys via PIN/social login), or modular (smart contract wallets with passkeys). See https://developers.circle.com/wallets.md. > Use CCTP V2 for crosschain transfers. CCTP natively transfers USDC and EURC via burn-and-mint, and supports permissionless wrapping of third-party assets via lock-and-mint. V1 is legacy; always use V2 unless V1 is specified or the chain requires it (Noble, Sui, and Aptos still require V1). Migration guide: https://developers.circle.com/cctp/migration-from-v1-to-v2.md. > Use Bridge Kit for frontend bridging. Wraps CCTP with a simpler SDK for user-facing apps. Use CCTP directly for backend transfers. > Gas Station vs Paymaster. Gas Station sponsors gas for Circle Wallet transactions. Paymaster lets users pay gas in USDC. Different use cases — read both overviews. > Gateway Nanopayments for sub-cent payments. Gasless USDC micropayments down to $0.000001 via x402 and batched settlement. For pay-per-request APIs, AI agent payments, streaming. > Look up USDC addresses per chain. Never hardcode — use https://developers.circle.com/stablecoins/usdc-contract-addresses.md. > Prefer SDKs over raw API calls. Node.js and Python SDKs handle auth, retries, and errors. > API key required. Bearer token in Authorization header. Testnet and mainnet use separate keys and may use different base URLs depending on the product. > Set up webhooks when available. Most operations are async. Webhooks deliver transaction confirmations and state changes. > When calling list endpoints, paginate using pageSize and pageAfter until no nextPageAfter cursor is returned—stopping at the first page silently misses records. > Building an AI agent? Start with the Agent Stack—Circle CLI, agent wallets, and nanopayments built for autonomous use cases: https://developers.circle.com/agent-stack.md. # Application types and states > Reference for all application types and their statuses Application types and states describe why an application exists, where it is in the review process, and which actions are available. ## Application types The application `type` field identifies the purpose of an application. | Type | Description | | - | - | | `ONBOARDING` | Initial application used to onboard a client. Partners can create this application type. | | `INFORMATION_UPDATE` | Application used to update customer information and send RFIs. Partners cannot create this application type. | | `PERIODIC_REVIEW` | Application used to require customers to review and resubmit information. Partners cannot create this application type. | ## Application statuses | Status | Description | | - | - | | `DRAFT` | Created but not yet submitted. Data can be added, updated, or deleted. | | `SUBMITTED` | Submitted for review. No modifications allowed. | | `IN_REVIEW` | Compliance review in progress (automated and manual checks). | | `PENDING_CUSTOMER_INFORMATION` | One or more RFIs issued. Partner must update data or documents and resubmit. | | `APPROVED` | Approved. Terminal state. | | `DENIED` | Denied. Terminal state. | | `CANCELLED` | Canceled. Terminal state. | ## Status transitions See [Application types](#application-types) for definitions of `ONBOARDING`, `PERIODIC_REVIEW`, and `INFORMATION_UPDATE`. ### `ONBOARDING` applications ```mermaid theme={null} flowchart LR DRAFT --> SUBMITTED DRAFT --> CANCELLED SUBMITTED --> IN_REVIEW IN_REVIEW --> PENDING_CUSTOMER_INFORMATION PENDING_CUSTOMER_INFORMATION --> SUBMITTED IN_REVIEW --> APPROVED IN_REVIEW --> DENIED ``` ### `PERIODIC_REVIEW` applications The system creates periodic review applications in `IN_REVIEW`, then moves them to `DRAFT` when partner action is required. ```mermaid theme={null} flowchart LR IN_REVIEW --> DRAFT DRAFT --> SUBMITTED DRAFT --> CANCELLED SUBMITTED --> IN_REVIEW IN_REVIEW --> PENDING_CUSTOMER_INFORMATION PENDING_CUSTOMER_INFORMATION --> SUBMITTED IN_REVIEW --> APPROVED IN_REVIEW --> DENIED ``` ### `INFORMATION_UPDATE` applications The system creates information update applications in `IN_REVIEW`. They move to `PENDING_CUSTOMER_INFORMATION` only when partner action is required. ```mermaid theme={null} flowchart LR IN_REVIEW --> APPROVED IN_REVIEW --> CANCELLED IN_REVIEW --> PENDING_CUSTOMER_INFORMATION PENDING_CUSTOMER_INFORMATION --> SUBMITTED SUBMITTED --> IN_REVIEW ``` See [Submit and track applications](/cpn/managed-payments/end-user-onboarding/howtos/submit-and-track-applications) for the submission and RFI workflow. ## Mutable vs. immutable states Partners can only modify application data (sections, documents) in these states: * **`DRAFT`**: Initial state after creation. Full read/write access. * **`PENDING_CUSTOMER_INFORMATION`**: RFIs issued. Partners can update the sections and documents referenced by the RFIs, then resubmit. All other states are immutable. API calls that attempt to modify data return a `409 Conflict` error. Saving section data in mutable states may trigger conditional changes. See [Conditional logic](/cpn/managed-payments/end-user-onboarding/concepts/conditional-logic) for details. ## Section statuses Each section in an application has its own status that tracks data completeness: | Status | Description | | - | - | | `not_started` | No data saved for this section | | `incomplete` | Some data saved but required fields are missing | | `complete` | All required fields are populated and valid | | `action_required` | An RFI targets a field in this section; update needed | Terminal states (`APPROVED`, `DENIED`, `CANCELLED`) are final. Applications cannot transition out of these states.