> ## Documentation Index > Fetch the complete documentation index at: https://docs.lumx.io/llms.txt > Use this file to discover all available pages before exploring further. # Integrate local-currency virtual accounts > A copy-paste prompt for named virtual accounts in your customer's own name — request the currencies, track provisioning, collect the deposit. Paste this prompt into your coding agent to collect in local currency through accounts issued in your customer's own name. The agent requests accounts with the customer, tracks each one through provisioning, and renders the deposit coordinates for every rail you collect on. ## Before you start * A Sandbox API key. See [Authentication](/get-started/authentication). * A webhook endpoint registered under **Developers > Webhooks** in the [Dashboard](https://dashboard.lumx.io). See [Webhooks](/developer/webhooks). ## Prompt ```text Prompt theme={null} You are a senior backend engineer adding Lumx virtual accounts to a B2B product that collects money in more than one country. Ground truth. Read both before writing any code and follow them over any prior knowledge: 1. https://docs.lumx.io/llms.txt — the documentation index. Every page has a .md twin at its own path. 2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec. Take field names, required flags and enum values from here; the prose carries the lifecycle the spec does not describe. Work against sandbox at https://api-sandbox.lumx.io with a server-side key sent as "Authorization: Bearer ". 1. Request the accounts when you create the customer. POST /customers takes an "accounts" array of currencies from BRL, USD, EUR, MXN and GBP. There is no endpoint that creates an account on its own — check the spec and confirm this before designing any screen that implies one. 2. Model the account lifecycle as a state machine over the status enum in the spec: AWAITING_ONBOARDING, REQUESTED, PROVISIONING, RFI, ACTIVE, REJECTED, INACTIVE, CLOSED. The prose documents seven of these; take the set from the spec and flag the difference. 3. Drive the transitions from the account.* webhooks — account.awaiting_onboarding through account.active — and reconcile with GET /accounts?customerId={id}. Paginate with size and cursor; do not assume one page. 4. Expect BRL, MXN, EUR and GBP to reach ACTIVE immediately after the customer is APPROVED, and USD to take up to one business day. Your UI has to show a pending account, not a missing one. 5. Get the deposit coordinates. GET /accounts returns id, customerId, status, currency and timestamps — no bank details. The coordinates come from POST /autoconversion-rules, in sourceDepositInfo, for a standing conversion, or from POST /transactions/on-ramp, in state.payment, for a single expected deposit. Pick one and say which in the code. 6. Render the coordinates per rail: brCode for PIX, clabe plus reference for SPEI, accountNumber with routingNumber or bic for USD, iban plus bic for SEPA (EUR), sortCode plus accountNumber for FPS (GBP). Take every field name from the spec or from the examples in the API reference, and flag anything you cannot find in either. Constraints: - The account is issued in your customer's name, not yours. Do not design a flow that pools several parties' funds in one account — read /compliance/nested-payments first. - One currency per account. A customer holds several accounts, and the rails available on each follow the currency. - Do not state a rate limit while paginating. None is published. Handle 429 TOO_MANY_REQUESTS with exponential backoff. Deliverables: - A provisioning state machine driven by webhooks, with the RFI and REJECTED paths handled. - A collection screen that renders deposit coordinates per rail from live API data. - A sandbox script that creates a customer with BRL and USD accounts and prints each status change. - A list of every field you could not confirm in either source. ``` ## How to use 1. Decide which currencies your customers actually need before running this. Requesting all five creates five accounts you then have to explain to a compliance reviewer. 2. Create the sandbox key and register the webhook endpoint yourself; the agent stops at the first authenticated call without them. 3. Check the agent's choice in step 5 against how your product collects — a standing rule and a per-deposit transaction are different products, and it should not decide that for you. ## What the prompt builds | **Endpoint** | **What the agent uses it for** | | :- | :- | | `POST /customers` | Requests the accounts, one per currency, when the customer is created | | `GET /accounts` | Reads each account's status and reconciles the webhooks | | `POST /autoconversion-rules` | Returns deposit coordinates for a standing conversion | | `POST /transactions/on-ramp` | Returns deposit coordinates for one expected deposit | ## Errors to expect These codes come from the [errors catalog](/developer/errors), for the resources this prompt uses. Match on `code`, not on `message`. | **Code** | **Status** | **When it happens** | | :- | :- | :- | | `ACCOUNT_NOT_FOUND` | 404 | Account does not exist. | | `ACCOUNT_NOT_ACTIVE` | 409 | Account is not in a usable state. | | `ACCOUNT_ALREADY_EXISTS` | 409 | Customer already has an account in that currency. | | `KYC_NOT_APPROVED` | 403 | Customer identity verification (KYC/KYB) is not approved. | ## Related resources Virtual accounts, provisioning, and status. Supported currencies, rails, and stablecoin pairs. Take a business or individual from signup to an approved customer. Convert every deposit to stablecoin with a standing rule. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.