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

# Customer onboarding

> Create a request, collect the required information, and track approval.

Start with create, submit, and status retrieval. Add the other operations only when the returned requirements or actions call for them.

## Integration flow

1. [Create a request](https://docs.blockradar.co/en/api-reference/customer-onboarding/create-request.md) for an existing customer. Save the returned customer ID and case ID.
2. Collect the information described by `data.requirements.schema`. See [Dynamic Forms](https://docs.blockradar.co/en/guides/dynamic-forms.md) for rendering and validation.
3. [Submit the request](https://docs.blockradar.co/en/api-reference/customer-onboarding/submit-request.md) with the completed object in `data`. If `data.initiated` is `false`, complete the missing requirements and submit again.
4. Follow any hosted steps or actions returned in the case. The required steps vary by provider and customer.
5. Listen for [webhooks](https://docs.blockradar.co/en/api-reference/customer-onboarding/webhooks.md) and [get the request](https://docs.blockradar.co/en/api-reference/customer-onboarding/get-request.md) for its latest saved details. Use [Refresh status](https://docs.blockradar.co/en/api-reference/customer-onboarding/refresh-request.md) to check the provider for updates.

Approval is recorded in `data.case.status`, not implied by a successful HTTP response. After approval, start a new fiat session for the customer.

## Handle the next step

| Case status | What to do |
| - | - |
| `draft`, `collecting_information`, `ready_for_submission` | Complete the current requirements and submit. |
| `action_required` | Follow the returned actions and hosted steps. |
| `awaiting_provider_submission`, `submitted`, `pending_admin_review`, `in_review` | Show a pending state and wait for updates. |
| `approved` | Continue with the customer’s fiat flow. Business eligibility still applies. |
| `rejected`, `failed`, `expired` | Show the reason and follow any available recovery actions. |

## Conditional operations

* **Documents:** prepare uploads when the schema requests files. Use the proxy upload endpoint only for proxy uploads. Document preview links are optional.
* **Hosted verification:** open the returned hosted step, then record its submission using its `sequenceIndex`.
* **Additional information:** submit an action when the case requests it.
* **Confirmation:** fetch and submit a confirmation form only when the workflow requires it.
* **Drafts and recovery:** save partial data to resume later, list previous requests, or reopen a request when `availableActions` includes `edit_and_resubmit`.

Always use the latest requirements, actions, and `availableActions` returned by the API.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.