> ## 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. # Build the BRL corridor end to end > A copy-paste prompt that builds the whole Brazil corridor in code — PIX in, USDC out, standing conversion, webhooks and reconciliation against cut-offs. Paste this prompt into your coding agent to build the Brazil corridor as working code, not as a currency pair on a page. The agent onboards a customer with a BRL account, chooses between a standing rule and a per-deposit on-ramp, quotes the conversion, and closes the loop with a payout. ## 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 building the Brazil corridor on Lumx: BRL in over PIX, stablecoin held, BRL or foreign currency out. Build the flow, not a converter. 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. Read /get-started/coverage for the supported pairs and /additional-information/sla-and-cutoffs for the timing. 2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec, for field names, required flags and enums. 1. Onboard the customer with POST /customers, passing accounts: ["BRL"]. BRL provisions immediately once the customer is APPROVED, so poll GET /accounts?customerId={id} until the account is ACTIVE and treat the wait as a product state. 2. Choose how BRL arrives, and write down why. A standing rule with POST /autoconversion-rules converts every deposit with no per-deposit call and returns a static PIX brCode. A per-deposit POST /transactions/on-ramp expects one known amount and returns a brCode for that amount. Recurring collection wants the rule; checkout wants the transaction. 3. Price it before the customer commits. POST /exchange-rates with type LOCKED returns an id and an expiresAt under a timelock of 30s, 1m or 5m, and with type FLOATING prices at execution. Pass the locked id on the transaction and handle EXCHANGE_RATE_EXPIRED as a re-quote, not an error screen. 4. Render the PIX payload correctly: the brCode is the string the payer pastes or scans, and for a standing rule the depositIdentifier embedded in it is what matches the deposit. Take both field names from the spec, not from memory. 5. Pick the stablecoin and the chain deliberately. Read the supported-pairs table: BRL converts to USDC and USDT on the chains listed there, and one chain is on-ramp only. Pass blockchain explicitly rather than relying on the project default. 6. Close the loop out. For BRL out, register a PIX destination with POST /destinations and settle with POST /transactions/off-ramp; for foreign currency out, use the destination branch for that rail. 7. Reconcile on PIX terms: PIX has no cut-off and runs 24/7/365, so a BRL leg that has not settled is a real problem rather than a timing artifact — unlike ACH, FEDWIRE, SWIFT and SEPA Credit Transfer, which have cut-offs or business-day windows. Constraints: - Only currencies and chains present in the spec's enums may appear in the code. Confirm each pair against the coverage table and flag any combination it does not list. - A deposit under the documented minimum for a standing rule is never converted, so validate the amount before showing a code. - Do not state a rate limit. None is published. Handle 429 TOO_MANY_REQUESTS with exponential backoff. Deliverables: - The chosen collection mode with the reason recorded in the code. - A quote-to-settlement path with expiry handled. - A sandbox run proving BRL in and BRL out, printing each status change. ``` ## How to use 1. Decide standing rule versus per-deposit transaction before running this, or check the agent's reason in step 2. It is the one choice that changes the whole product. 2. Pick the chain with whoever holds the treasury; fees and finality differ and the code should not decide it. 3. Test with a sandbox amount above the minimum, or the conversion never starts and the failure looks like a bug. ## What the prompt builds | **Endpoint** | **What the agent uses it for** | | :- | :- | | `POST /customers` | Creates the customer with a BRL account | | `GET /accounts` | Waits for the BRL account to become active | | `POST /autoconversion-rules` | Creates a standing rule with a static PIX code | | `POST /exchange-rates` | Quotes the conversion before the customer commits | | `POST /transactions/on-ramp` | Creates a per-deposit on-ramp with a PIX code for one amount | | `POST /destinations` | Registers the destination for the payout | | `POST /transactions/off-ramp` | Sends BRL or foreign currency out | ## 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** | | :- | :- | :- | | `EXCHANGE_RATE_EXPIRED` | 422 | Locked rate has expired. | | `MINIMUM_AMOUNT_NOT_MET` | 422 | Amount is below the supported minimum for the currency. | | `ACCOUNT_NOT_ACTIVE` | 409 | Account is not in a usable state. | | `INSUFFICIENT_BALANCE` | 422 | Balance is too low for the operation. | ## Related resources Supported currencies, rails, and stablecoin pairs. Convert every deposit with a standing rule. Take fiat in and deliver stablecoin to the customer's wallet. Convert every deposit to stablecoin with a standing rule. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.