> ## 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.

# Submit onboarding application

> Submit an onboarding application using the End User Onboarding API in sandbox

Walk through the full application lifecycle: create a client, populate its
sections, upload a document, and submit for review.

<Note>
  The End User Onboarding API base URL is `https://api-sandbox.circle.com` for
  sandbox and `https://api.circle.com` for production. All requests require a
  Bearer token obtained via Circle key exchange in the `Authorization` header. All
  `POST` requests require an `X-Idempotency-Key` header with a client-generated
  UUID v4.
</Note>

## Prerequisites

Before you begin, ensure that you've:

* Obtained an API key for the End User Onboarding API from the
  [CPN Console](https://console.circle.com) (**Developer > API Keys**). Use this
  key to obtain a Bearer token through the Circle key exchange.
* (Recommended) Set up a webhook subscription for application status changes to
  receive real-time updates instead of polling. See
  [Webhook endpoints](/api-reference/webhook-endpoints).

## Step 1: Create a client and initialize the application

Create a client and start an onboarding application in one request:

```shell theme={null}
curl --request POST \
  --url https://api-sandbox.circle.com/v1/partner/clients \
  --header "Authorization: Bearer ${YOUR_API_KEY}" \
  --header "Content-Type: application/json" \
  --header "Accept: application/json" \
  --data '{
    "clientName": "Acme Trust Co.",
    "country": "US",
    "clientType": "business",
    "businessDetails": {
      "natureOfBusiness": "trust",
      "institutionType": "trust"
    }
  }'
```

For the full request schema, see
[Create Partner Client](/api-reference/end-user-onboarding/create-partner-client).

**Example response:**

```json theme={null}
{
  "data": {
    "clientEntityId": "880e8400-e29b-41d4-a716-446655440099",
    "applicationId": "550e8400-e29b-41d4-a716-446655440000"
  }
}
```

Save the `applicationId`. You'll use it in all subsequent steps.

<Note>
  Using the same `clientName` and `country` combination returns a `409 Conflict`
  error. Use a different `clientName` to create another client in the same
  country.
</Note>

## Step 2: Discover the schema

The sections and fields in an application aren't fixed. They're defined by a
JSON Schema (draft 2020-12) specific to the business type you set with
`natureOfBusiness` and `institutionType`. Read the schema before you save data
so you know which sections and fields apply. Don't assume field names.

Retrieve the schema for your application:

```shell theme={null}
curl --request GET \
  --url https://api-sandbox.circle.com/v1/onboarding/partner/applications/${APPLICATION_ID}/schema \
  --header "Authorization: Bearer ${YOUR_API_KEY}"
```

Top-level properties map to section names, and each section lists its fields,
types, and validation rules. To list sections with their completion status
instead, call
`GET /v1/onboarding/partner/applications/${APPLICATION_ID}/sections`.

For schema discovery, conditional fields, and bulk save, see
[Create and populate applications](/cpn/managed-payments/end-user-onboarding/howtos/create-and-populate-applications).

## Step 3: Save section data

Using the field names from the schema, populate a section. This example saves
the `basicBusinessInfo` section for the trust application created in Step 1. The
sections and fields for your application depend on its own schema:

```shell theme={null}
curl --request PUT \
  --url https://api-sandbox.circle.com/v1/onboarding/partner/applications/${APPLICATION_ID}/sections/basicBusinessInfo \
  --header "Authorization: Bearer ${YOUR_API_KEY}" \
  --header 'Content-Type: application/json' \
  --data '{
    "businessWebsite": "https://example.com",
    "businessWebsiteProvided": true
  }'
```

<Note>
  Section and field names vary by business type. Saving a field that isn't in
  the section's schema returns a `422` error with per-field details. Use the
  schema from Step 2 to see the fields for your application.
</Note>

The response confirms the section status changed to `complete`:

```json theme={null}
{
  "data": {
    "data": {
      "businessWebsite": "https://example.com",
      "businessWebsiteProvided": true
    },
    "sections": [
      { "sectionName": "basicBusinessInfo", "status": "complete" },
      { "sectionName": "physicalBusinessAddress", "status": "not_started" }
    ],
    "sectionsChanged": false
  }
}
```

Repeat for each remaining section. See
[Create and populate applications](/cpn/managed-payments/end-user-onboarding/howtos/create-and-populate-applications)
for details on the schema, bulk save, and conditional sections.

## Step 4: Upload a document

Upload a supporting document and link it to a schema field:

```shell theme={null}
curl --request POST \
  --url https://api-sandbox.circle.com/v1/onboarding/partner/applications/${APPLICATION_ID}/documents \
  --header "Authorization: Bearer ${YOUR_API_KEY}" \
  --header 'X-Idempotency-Key: ${IDEMPOTENCY_KEY}' \
  --form 'fileContent=@passport.pdf' \
  --form 'fileName=passport.pdf' \
  --form 'datumName=passport_document' \
  --form 'issuedCountry=US'
```

The response returns the new document ID:

```json theme={null}
{
  "data": {
    "documentId": "550e8400-e29b-41d4-a716-446655440002"
  }
}
```

See
[Upload documents](/cpn/managed-payments/end-user-onboarding/howtos/upload-documents)
for details on required fields and linking documents to array entities.

## Step 5: Submit the application

After all sections are `complete` and required documents are uploaded, submit
the application:

```shell theme={null}
curl --request POST \
  --url https://api-sandbox.circle.com/v1/onboarding/partner/applications/${APPLICATION_ID}/submit \
  --header "Authorization: Bearer ${YOUR_API_KEY}" \
  --header 'Content-Type: application/json' \
  --header 'X-Idempotency-Key: ${IDEMPOTENCY_KEY}' \
  --data '{
    "endUserIpAddress": "203.0.113.42",
    "endUserAgreesToTermsOfService": true
  }'
```

<Note>
  If your integration presents compliance certifications directly to end users
  (for example, in a GUI where users read and agree to terms), fetch the active
  certifications with `GET /v1/onboarding/partner/applications/${APPLICATION_ID}
      /certifications` before submitting and include the agreed certification UUIDs
  in a `certificationIds` array in the request body. See [Submit and track
  applications](/cpn/managed-payments/end-user-onboarding/howtos/submit-and-track-applications)
  for details.
</Note>

The application moves to `SUBMITTED`:

```json theme={null}
{
  "data": {
    "applicationId": "550e8400-e29b-41d4-a716-446655440000",
    "status": "SUBMITTED"
  }
}
```

## Step 6: Check application status

Poll for the current status or use webhook notifications (if you set up a
subscription in the prerequisites) for real-time updates:

```shell theme={null}
curl --request GET \
  --url https://api-sandbox.circle.com/v1/onboarding/partner/applications/${APPLICATION_ID} \
  --header "Authorization: Bearer ${YOUR_API_KEY}"
```

The application progresses through `IN_REVIEW` and reaches a terminal status of
`APPROVED` or `DENIED`. If the compliance team needs more information, the
status changes to `PENDING_CUSTOMER_INFORMATION`.

For more details, see:

* [Application types and states](/cpn/managed-payments/end-user-onboarding/references/application-states):
  the full lifecycle of an application
* [Submit and track applications](/cpn/managed-payments/end-user-onboarding/howtos/submit-and-track-applications):
  the submission workflow
* [Handle requests for information](/cpn/managed-payments/end-user-onboarding/howtos/handle-rfis):
  responding when the compliance team needs more data