Build a product
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.
// PROMPT
{ "type": "INDIVIDUAL", "name": "William Default", "taxId": "100.100.100-01", "birthDate": "1990-01-01" }
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 the other rails in the table.
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.
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.
Pick the chain with whoever holds the treasury; fees and finality differ and the code should not decide it.
Test with a sandbox amount above the minimum, or the conversion never starts and the failure looks like a bug.
Discover how our infrastructure can seamlessly integrate stablecoins into your financial operations quickly, securely, and efficiently.

