> ## 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. # Refresh status > Check the provider for a status update. Send an empty JSON object for the normal flow: Check the provider for a status update. Send an empty JSON object for the normal flow: ```json theme={null} {} ``` Read `data.case.status` after the call. A successful response can still mean verification is pending. An already approved request returns success without creating new hosted steps. If no provider status update is available, supported hosted steps can be renewed when `availableActions` includes `refresh_provider_steps`. Normal renewal requires at least one unsubmitted hosted step. Use `force: true` only to intentionally regenerate supported hosted steps; it does not bypass terminal-state checks. After approval, start a new fiat session to use the updated onboarding status. You can also receive status changes through [webhooks](https://docs.blockradar.co/en/api-reference/customer-onboarding/webhooks.md). ## OpenAPI ````yaml post /v1/customers/{customerId}/onboarding-requests/{caseId}/refresh openapi: 3.0.3 info: title: Blockradar Documentation description: >- The OpenAPI specification of the Blockradar API that enables fintechs and developers to seamlessly integrate stablecoin deposits and payments into their products. version: 1.0.0 contact: {} servers: - url: https://api.blockradar.co security: - apiKey: [] tags: - name: Rewards description: >- Non-custodial yield (Earn) on stablecoins via DeFi (Aave) strategies. Deposit, withdraw, preview fees, and read positions and earnings at the business, wallet, and sub-address level. Amounts are returned net of the platform fee, which applies only to interest earned. - name: Wallet description: >- Wallet Management System Comprehensive wallet management API for multi-blockchain operations. This system handles wallet creation, configuration, balance monitoring, and integration with various blockchain networks. Core Functionality: - Multi-blockchain wallet creation and management - Balance monitoring and asset tracking - Auto-settlement rule configuration - Gateway wallet integration - Address generation and management - Transaction monitoring and processing - name: Addresses description: >- Address Management System Comprehensive blockchain address management API for operations. This system handles address creation, validation, monitoring, and management across multiple blockchain networks. Core Functionality: - Multi-blockchain address generation - Address validation and verification - Balance monitoring and tracking - Transaction history management - Address labeling and organization - Integration with wallet systems - Real-time address monitoring - name: Asset - name: Transactions - name: Withdraw description: >- The Withdraw feature allows you to programmatically withdraw stablecoins from your master wallet with ease - name: Withdraw Fiat - name: Signing description: >- Signing service for plain text messages, raw transactions, and EIP-712 typed data. Message signing, transaction signing, and sign-and-broadcast are available on EVM, Tron, Solana, and Stellar. Typed data signing (EIP-712, including EIP-2612 Permit and EIP-3009 TransferWithAuthorization) is EVM-only. - name: Swap description: >- The Swap feature enables users to exchange one stabelcoin asset for another across different blockchains. This feature provides a seamless way to convert between different stablecoins while maintaining security and compliance standards. - name: Liquidity Pool - name: Virtual Accounts description: >- Virtual Accounts API provides endpoints for managing virtual bank accounts linked to master wallets or child addresses. This API enables businesses to: - Create virtual accounts for customers to receive payments - Retrieve virtual account details - Activate/deactivate virtual accounts **Virtual Account Types:** Virtual accounts support different types with varying behaviors: 1. **AUTO_FUNDING** (Default): - Automatically mints stablecoin when fiat payments are received - Transfers the stablecoin to the linked wallet/address immediately - Best for real-time payment processing **How It Works - Auto-Funding Flow (AUTO_FUNDING type only):** When a customer sends fiat currency to a virtual account with type AUTO_FUNDING: 1. **Payment Receipt**: The payment is received in the virtual account 2. **Automatic Minting**: The system automatically mints the stablecoin equivalent 3. **Blockchain Transfer**: The minted stablecoin is transferred to the virtual account's linked wallet or address **Note**: The auto-funding flow only applies to virtual accounts with type `AUTO_FUNDING`. Other types have different processing behaviors. ## Prerequisites Before creating virtual accounts, ensure: - **Compliance requirements must be completed** (see [Compliance Requirements](http://localhost:3000/essentials/virtual-accounts#compliance-requirements) section below) - **Virtual accounts feature must be enabled** for your business (reach out to [support@blockradar.co](https://mailto:support@blockradar.co) or use live chat on the dashboard to enable the feature after compliance approval) - **Environment-aware routing** - testnet requests use only testnet routes and wallets, while mainnet requests use only mainnet routes and wallets - **Master Wallet must support stablecoin asset** - Your account plan must include stablecoin access (upgrade from Dashboard → Settings → Subscription if needed) **Supported Currency:** - Fiat: NGN (Nigerian Naira) - Stablecoin: cNGN - minted automatically on blockchain (for AUTO_FUNDING type) - name: Auto Settlements description: >- Creates a new auto settlement rule for a wallet. Auto settlement automatically transfers/swap assets based on configured rules when certain conditions are met. Rules can be configured for: - Source blockchain and assets - Destination blockchain and asset - Amount ranges (min/max) - Slippage tolerance - Gateway vs non-gateway wallets Gateway rules are required for testnet wallets and must have matching source/destination assets. - name: Smart Contract description: >- This API provides endpoints for interacting with smart contracts on the blockchain. It allows for reading contract data, executing contract functions, and estimating network fees. - name: Gateway description: >- The Gateway feature enables you to programmatically deposit USDC into a unified, chain-abstracted balance and instantly mint USDC on any supported blockchain, streamlining crosschain transfers and eliminating manual bridging steps and rebalancing complexities. - name: Payment Links description: >- The Payment Pages API provides a quick and secure way to collect payment for servcies. - name: Beneficiaries description: >- This API allows you to create beneficiaries with automatic settlements to your external wallets on a periodic basis. Example frequencies: INSTANT, DAILY, WEEKLY, MONTHLY, YEARLY - name: AML description: >- The AML (Anti Money Laundering) API provides a quick way for you to check if an address is blacklisted or sanctioned - name: Asset Recovery description: >- Enables the recovery (salvage) of both native blockchain assets and tokens from a specified sender address to a recipient address. This feature supports emergency fund recovery and asset consolidation operations. - name: Miscellaneous description: >- The Miscellaneous API are supporting APIs that can be used to provide more details to other APIs. - name: Asset1 - name: Blockchain - name: Webhooks description: >- Webhooks allow you to set up a notification system that can be used to receive updates on certain requests made to the Blockradar API. To see full list and instructions [https://docs.blockradar.co/essentials/webhooks](https://docs.blockradar.co/essentials/webhooks) ## - name: Deposit - name: Withdraw1 - name: Swap1 - name: Gateway1 paths: /v1/customers/{customerId}/onboarding-requests/{caseId}/refresh: post: tags: - Customer Onboarding summary: Refresh status description: >- Check the provider for a status update. Send an empty JSON object for the normal flow: operationId: CustomerOnboardingController_refreshOnboardingRequest parameters: - $ref: '#/components/parameters/CustomerId' - $ref: '#/components/parameters/OnboardingCaseId' requestBody: required: true description: >- Send {} to check provider verification or refresh normally. force is optional and defaults to false. content: application/json: schema: $ref: '#/components/schemas/RefreshOnboardingCaseDto' example: {} responses: '200': description: >- Verification synchronized, hosted steps refreshed, or case already approved. content: application/json: schema: $ref: '#/components/schemas/CustomerOnboardingCaseOperationResponse' examples: approved: summary: Provider approval synchronized value: status: true message: Onboarding case approved successfully data: customerId: 18d2f159-e0cd-4a45-b735-e9dfe0f7520a case: id: 8392013d-2481-47c9-b5e3-b61b22b8ff82 businessId: ec01bc89-d2d8-47fc-8d4c-0616d859915d customerId: 18d2f159-e0cd-4a45-b735-e9dfe0f7520a providerId: 1128dd40-2c94-4c16-a6bf-fbbc6afee52c subjectType: customer status: approved mode: hosted_only feature: offramp hostedSessions: [] actions: [] availableActions: [] reason: null createdAt: '2026-10-31T10:00:00.000Z' updatedAt: '2026-10-31T10:15:00.000Z' alreadyApproved: summary: Case was already approved value: status: true message: Onboarding case is already approved data: customerId: 18d2f159-e0cd-4a45-b735-e9dfe0f7520a case: id: 8392013d-2481-47c9-b5e3-b61b22b8ff82 businessId: ec01bc89-d2d8-47fc-8d4c-0616d859915d customerId: 18d2f159-e0cd-4a45-b735-e9dfe0f7520a providerId: 1128dd40-2c94-4c16-a6bf-fbbc6afee52c subjectType: customer status: approved mode: hosted_only feature: offramp hostedSessions: [] actions: [] availableActions: [] reason: null createdAt: '2026-10-31T10:00:00.000Z' updatedAt: '2026-10-31T10:15:00.000Z' '400': description: Invalid data or operation not supported in the current case state. content: application/json: schema: $ref: '#/components/schemas/CustomerFiatError' '404': description: >- Customer or matching customer onboarding case not found for the authenticated business. content: application/json: schema: $ref: '#/components/schemas/CustomerFiatError' components: parameters: CustomerId: name: customerId in: path required: true description: Customer identifier. schema: type: string format: uuid OnboardingCaseId: name: caseId in: path required: true description: Customer onboarding case identifier. schema: type: string format: uuid schemas: RefreshOnboardingCaseDto: type: object properties: force: type: boolean default: false description: >- Force hosted-session regeneration only in the supported renewal path. Does not bypass provider verification, terminal-state checks or ownership. With false, existing sessions must exist and not all be submitted. CustomerOnboardingCaseOperationResponse: type: object properties: status: type: boolean example: true message: type: string data: type: object properties: customerId: type: string format: uuid case: $ref: '#/components/schemas/CustomerOnboardingCase' required: - customerId - case required: - status - message - data CustomerFiatError: type: object properties: statusCode: type: integer message: oneOf: - type: string - type: array items: type: string details: $ref: '#/components/schemas/CustomerFiatRecoveryDetails' requestId: type: string required: - statusCode - message CustomerOnboardingCase: type: object properties: id: type: string format: uuid businessId: type: string format: uuid customerId: type: string format: uuid providerId: type: string format: uuid subjectType: type: string enum: - customer status: $ref: '#/components/schemas/OnboardingCaseStatus' mode: type: string enum: - api_only - hosted_only - hybrid - manual feature: type: string nullable: true description: >- Requested onboarding feature, such as offramp, onramp_payment_order or onramp_virtual_account. providerReference: type: string nullable: true routeIntent: type: object nullable: true data: type: object nullable: true hostedSessions: type: array nullable: true items: type: object reason: type: string nullable: true metadata: type: object nullable: true createdAt: type: string format: date-time updatedAt: type: string format: date-time actions: type: array items: type: object additionalProperties: true description: >- Current onboarding actions, including each action ID, type, status and schema. availableActions: type: array items: type: string enum: - edit_and_resubmit - refresh_provider_steps description: >- Current follow-up operations supported by this provider and case state. required: - id - businessId - customerId - providerId - subjectType - status - mode - createdAt - updatedAt CustomerFiatRecoveryDetails: type: object properties: code: type: string enum: - CUSTOMER_ONBOARDING_REQUIRED - CUSTOMER_ONBOARDING_PENDING - CUSTOMER_ONBOARDING_REJECTED - CUSTOMER_PROVIDER_UNAVAILABLE - CUSTOMER_IDENTITY_UNSUPPORTED - OFFRAMP_ROUTE_UNSUPPORTED - OFFRAMP_BUSINESS_NOT_ELIGIBLE - FIAT_WITHDRAWAL_SESSION_EXPIRED - FIAT_WITHDRAWAL_SESSION_MISMATCH - FIAT_WITHDRAWAL_SESSION_UNAVAILABLE - FIAT_WITHDRAWAL_SESSION_PRICING_CHANGED - FIAT_DEPOSIT_SESSION_EXPIRED - FIAT_DEPOSIT_SESSION_MISMATCH - FIAT_DEPOSIT_SESSION_UNAVAILABLE customerId: type: string format: uuid provider: type: object properties: id: type: string format: uuid slug: type: string name: type: string required: - id - slug - name onboarding: type: object properties: caseId: type: string nullable: true status: type: string nullable: true providerStatus: type: string nullable: true action: oneOf: - type: object properties: type: type: string enum: - create_case method: type: string enum: - POST path: type: string example: >- /v1/customers/18d2f159-e0cd-4a45-b735-e9dfe0f7520a/onboarding-requests body: type: object properties: provider: type: string type: type: string enum: - onramp - offramp required: - provider - type required: - type - method - path - body - type: object properties: type: type: string enum: - resume_case - wait method: type: string enum: - GET path: type: string required: - type - method - path - type: object properties: type: type: string enum: - contact_support required: - type required: - code description: >- Onboarding recovery failures include customerId, provider and onboarding.action. Unsupported identity and route failures can contain fewer fields. Follow only the returned action. OnboardingCaseStatus: type: string enum: - draft - collecting_information - ready_for_submission - submitted - action_required - pending_admin_review - in_review - approved - rejected - failed - expired securitySchemes: apiKey: type: apiKey name: x-api-key in: header ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.