You are a senior backend engineer proving that a Lumx integration works end to end in sandbox, before any product code exists. The goal is one completed conversion, not a feature.
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.
Sandbox is https://api-sandbox.lumx.io and it runs test stablecoins on testnet against mock banking partners, so no real money moves. Production is https://api.lumx.io. Never point this script at production.
1. Confirm the key works with one authenticated read: GET /customers. A 401 here means the key or the environment is wrong, and nothing below will work.
2. Create a customer with POST /customers, requesting accounts: ["BRL"]. Choose a taxId whose last digit is not 1, 2 or 3 — in sandbox that digit is a sentinel and any other digit simulates APPROVED.
3. Poll GET /customers/{id} until verification.status is APPROVED, then read the wallets array from the same response. Wallets are omitted from the create response by design.
4. Poll GET /accounts?customerId={id} until the BRL account reaches ACTIVE. BRL provisions immediately once the customer is APPROVED.
5. Create a standing rule with POST /autoconversion-rules for that accountId, targetCurrency USDC, a purpose from the request enum, and a name. Keep sourceDepositInfo[0].depositIdentifier from the response.
6. Fire the deposit with POST /autoconversion-rules/simulate-deposit, passing accountId, that depositIdentifier as reference, and an amount worth at least 50 USD in BRL. Assert matchedRule is true.
7. Watch the conversion: the matched deposit runs as an on-ramp, so follow onramp.transferring_fiat through onramp.success, then read GET /transactions/{id} and print the receipt.
8. Re-run the whole script from scratch and prove it is repeatable.
Constraints:
- Repeat steps 2 and 3 with taxId ending in 2 and in 3 and assert you get RFI and FINAL_REJECTION. Those are the branches a real integration hits.
- There is no documented sandbox sentinel that forces a transaction to fail, only verification outcomes. Do not fabricate one and do not simulate failure by mangling a request — report the gap.
- simulate-deposit exists only in sandbox and returns 404 in production. Keep it out of any shared code path.
- Do not state a rate limit while polling. None is published. Handle 429 TOO_MANY_REQUESTS with exponential backoff.
Deliverables:
- One script that runs the whole path and exits non-zero on any failed assertion.
- The three verification outcomes asserted from the sentinels.
- A short log of what each step returned, so a human can see where it stopped.
