> ## 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. # Create a beneficiary > Registers a new fiat payout beneficiary for a supported payment corridor. The beneficiary is created in `INACTIVE` status and undergoes asynchronous risk screening. Poll `GET /v1/beneficiaries/{id}` until `status` is `ACTIVE` before using it in a payout. Bank/account fields (e.g. `CLABE`, `IBAN`) go in `bankAccount`; travel-rule / PII fields (e.g. `BENEFICIARY_NAME`, `BENEFICIARY_ADDRESS`) go in `travelRule`. Use `GET /v1/beneficiaries/requirements` to discover which fields are required for a corridor. Beneficiary records are immutable. To correct a registration error, soft-delete the record (`DELETE /v1/beneficiaries/{id}`) and register a new one. ## OpenAPI ````yaml openapi/managed-payments.yaml post /v1/beneficiaries openapi: 3.0.2 info: version: ${version} title: Managed Payments API description: | The Managed Payments API enables Payment Service Providers (PSPs) to create and manage sub-client accounts for stablecoin settlement, and to send fiat payouts to registered beneficiaries worldwide. servers: - url: https://api-sandbox.circle.com - url: https://api.circle.com security: [] tags: - name: Managed Payments Accounts description: Create and manage sub-client accounts for Managed Payments PSPs. - name: Managed Payments Credit description: Get credit line details and wire instructions for repayment. - name: Managed Payments Credit Transfers description: Create and manage credit transfers (drawdowns) against a credit line. - name: Managed Payments Transfers description: >- Create and manage internal account-to-account transfers for Managed Payments. - name: Managed Payments Fiat Payouts description: > Register and manage fiat payout beneficiaries, discover supported corridors and field requirements, and create locked FX quotes for cross-border fiat payouts. paths: /v1/beneficiaries: post: tags: - Managed Payments Fiat Payouts summary: Create a beneficiary description: > Registers a new fiat payout beneficiary for a supported payment corridor. The beneficiary is created in `INACTIVE` status and undergoes asynchronous risk screening. Poll `GET /v1/beneficiaries/{id}` until `status` is `ACTIVE` before using it in a payout. Bank/account fields (e.g. `CLABE`, `IBAN`) go in `bankAccount`; travel-rule / PII fields (e.g. `BENEFICIARY_NAME`, `BENEFICIARY_ADDRESS`) go in `travelRule`. Use `GET /v1/beneficiaries/requirements` to discover which fields are required for a corridor. Beneficiary records are immutable. To correct a registration error, soft-delete the record (`DELETE /v1/beneficiaries/{id}`) and register a new one. operationId: createBeneficiary requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/BeneficiaryCreationRequest' examples: MX SPEI individual: value: idempotencyKey: a1b2c3d4-e5f6-7890-abcd-ef1234567890 refId: d4e5f6a1-b2c3-7890-abcd-ef1234567890 nickname: Vendor A - MXN customerType: INDIVIDUAL destinationCountry: MX destinationCurrency: MXN paymentMethod: SPEI bankAccount: CLABE: 12345678901234568 travelRule: BENEFICIARY_NAME: Alice Garcia BENEFICIARY_ADDRESS: STREET: Av. Reforma 100 CITY: Ciudad de Mexico STATE_PROVINCE: CDMX POSTAL_CODE: '06600' COUNTRY: MX responses: '201': description: >- Beneficiary registered. Screening is asynchronous; `status` is `INACTIVE`. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' Location: description: URL of the created beneficiary. schema: type: string content: application/json: schema: type: object properties: data: $ref: '#/components/schemas/Beneficiary' examples: Beneficiary created: value: data: id: a1b2c3d4-e5f6-7890-abcd-ef1234567890 idempotencyKey: a1b2c3d4-e5f6-7890-abcd-ef1234567890 refId: d4e5f6a1-b2c3-7890-abcd-ef1234567890 nickname: Vendor A - MXN customerType: INDIVIDUAL destinationCountry: MX destinationCurrency: MXN paymentMethod: SPEI status: INACTIVE fieldManifest: '["BENEFICIARY_ADDRESS","BENEFICIARY_NAME","CLABE"]' createDate: '2026-08-12T15:30:45.123Z' updateDate: '2026-08-12T15:30:45.123Z' '400': description: Invalid request body or unsupported corridor. '401': description: Unauthorized. security: - bearerAuth: [] components: schemas: BeneficiaryCreationRequest: type: object description: Request body for registering a new fiat payout beneficiary. required: - idempotencyKey - customerType - destinationCountry - destinationCurrency - paymentMethod - bankAccount - travelRule properties: idempotencyKey: type: string format: uuid description: Client-generated UUID for idempotent submission. example: a1b2c3d4-e5f6-7890-abcd-ef1234567890 refId: type: string format: uuid description: Optional customer-assigned reference identifier. example: d4e5f6a1-b2c3-7890-abcd-ef1234567890 nickname: type: string description: Optional display label for this beneficiary. example: Vendor A - MXN customerType: type: string enum: - INDIVIDUAL - BUSINESS description: Whether the beneficiary is an individual or a business. destinationCountry: type: string description: ISO 3166-1 alpha-2 destination country code. example: MX destinationCurrency: type: string description: Destination fiat currency code. example: MXN paymentMethod: type: string description: > Payment rail. Must match a supported corridor rail. Examples: `SPEI`, `ACH-BANK-TRANSFER`, `SD-ACH`, `SEPA`, `WIRE`, `PIX`. example: SPEI bankAccount: type: object additionalProperties: type: string description: > Bank and account fields required by the corridor. Keys are the field names returned by `GET /v1/beneficiaries/requirements` with type `TEXT` (excluding travel-rule fields). Values must satisfy any `pattern` constraint. example: CLABE: 12345678901234568 travelRule: type: object additionalProperties: {} description: > Beneficiary travel-rule / PII fields required by the corridor. Keys are the field names returned by `GET /v1/beneficiaries/requirements` for travel-rule fields (prefixed `BENEFICIARY_`). `ADDRESS` type values are nested objects. example: BENEFICIARY_NAME: Alice Garcia BENEFICIARY_ADDRESS: STREET: Av. Reforma 100 CITY: Ciudad de Mexico STATE_PROVINCE: CDMX POSTAL_CODE: '06600' COUNTRY: MX Beneficiary: type: object description: A registered fiat payout beneficiary. required: - id - idempotencyKey - customerType - destinationCountry - destinationCurrency - paymentMethod - status - fieldManifest - createDate - updateDate properties: id: type: string format: uuid description: Unique identifier for the beneficiary. example: a1b2c3d4-e5f6-7890-abcd-ef1234567890 idempotencyKey: type: string format: uuid description: Idempotency key supplied at registration. example: a1b2c3d4-e5f6-7890-abcd-ef1234567890 refId: type: string format: uuid description: Customer-assigned reference identifier. Omitted if not provided. example: d4e5f6a1-b2c3-7890-abcd-ef1234567890 nickname: type: string description: Display label. Omitted if not provided. example: Vendor A - MXN customerType: type: string enum: - INDIVIDUAL - BUSINESS description: Whether the beneficiary is an individual or a business. destinationCountry: type: string description: ISO 3166-1 alpha-2 destination country code. example: MX destinationCurrency: type: string description: Destination fiat currency code. example: MXN paymentMethod: type: string description: Payment rail (e.g. `SPEI`, `ACH-BANK-TRANSFER`, `SEPA`, `WIRE`). example: SPEI status: $ref: '#/components/schemas/BeneficiaryStatus' riskDecision: type: string enum: - ACTIVE - DENIED description: Outcome of risk screening. Absent before screening completes. riskScreenedDate: type: string format: date-time description: >- ISO 8601 timestamp when risk screening completed. Absent before screening completes. example: '2026-08-12T15:31:20.000Z' fieldManifest: type: string description: JSON-encoded sorted array of field names submitted at registration. example: '["BENEFICIARY_ADDRESS","BENEFICIARY_NAME","CLABE"]' createDate: type: string format: date-time description: ISO 8601 creation timestamp. example: '2026-08-12T15:30:45.123Z' updateDate: type: string format: date-time description: ISO 8601 last-update timestamp. example: '2026-08-12T15:30:45.123Z' BeneficiaryStatus: type: string enum: - INACTIVE - ACTIVE - DENIED - STALE - DELETED description: > Lifecycle status of a beneficiary. - `INACTIVE` — registered, pending risk screening. - `ACTIVE` — risk-screened and approved; eligible for payouts. - `DENIED` — rejected by risk screening; cannot be used for payouts. - `STALE` — corridor requirements have changed since registration; re-register to use. - `DELETED` — soft-deleted; cannot be used for payouts. headers: XRequestId: description: >- Universally unique identifier (UUID v4) for the request. Helpful for identifying a request when communicating with Circle support. schema: type: string format: uuid example: 2adba88e-9d63-44bc-b975-9b6ae3440dde securitySchemes: bearerAuth: type: http scheme: bearer ````