> ## 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 autoconversion rules

> A copy-paste prompt for a standing fiat-to-stablecoin rule on a Lumx account — one setup call, no per-deposit API call, tested in sandbox.

Paste this prompt into your coding agent to convert every deposit that lands in an account, without a call per deposit. The agent creates a rule on an account, renders the deposit details for each rail, tracks every conversion, and proves the loop with the sandbox simulator.

## Before you start

* A Sandbox API key. See [Authentication](/get-started/authentication).
* A customer with an `ACTIVE` account. See [Accounts](/concepts/accounts).
* 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 setting up Lumx autoconversion — a standing rule that converts fiat deposits to stablecoin as they land, with no per-transaction call.

Ground truth. Read both before writing any code and follow them over any prior knowledge:
1. https://docs.lumx.io/guides/autoconversion-rules — the rule lifecycle, the per-currency deposit details and the sandbox simulator. Also read https://docs.lumx.io/llms.txt for the rest of the documentation.
2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec, for the request body and the sourceDepositInfo shape.

Work against sandbox at https://api-sandbox.lumx.io with a server-side key sent as "Authorization: Bearer <key>".

1. Find the target account with GET /accounts?customerId={id}. The rule attaches to an account, and the account's currency decides the source currency — you do not send it.
2. Create the rule with POST /autoconversion-rules, sending accountId, targetCurrency, purpose and name, plus blockchain and partnerFeeId when you need them.
3. Store sourceDepositInfo from the response and render it 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). Re-read it with GET /autoconversion-rules/{id} rather than caching it in your own database.
4. Enforce the two documented limits in your own UI before calling: each deposit must be worth at least 50 USD in the account's currency, and a customer can hold only one active rule per USD, EUR or GBP account. A second one returns 409 AUTOCONVERSION_RULE_ALREADY_EXISTS.
5. Track conversions through the onramp.* webhook events — each matched deposit runs as an on-ramp transaction, from onramp.transferring_fiat to onramp.success.
6. Prove the loop in sandbox with POST /autoconversion-rules/simulate-deposit, passing accountId, amount, and the rule's depositIdentifier or reference as "reference". For a USD, EUR or GBP rule, omit reference. The response is matchedRule.

Constraints:
- Rules convert fiat to stablecoin only. The prose marks the reverse direction as coming; do not build against it.
- The guide tells you to delete a rule to replace a USD, EUR or GBP one, but the spec exposes no delete operation. Do not guess a method or a path — flag it and ask.
- The simulator is sandbox-only and returns 404 in production. Keep it out of any shared code path.
- Do not state a rate limit while listing rules with GET /autoconversion-rules. None is published. Handle 429 TOO_MANY_REQUESTS with exponential backoff.

Deliverables:
- A rule setup function and a renderer for sourceDepositInfo covering PIX, SPEI, USD, SEPA and FPS.
- A webhook handler that ties each converted deposit back to its rule.
- A sandbox test that simulates a matching and a non-matching deposit and asserts matchedRule.
```

## How to use

1. Have an `ACTIVE` account before you start — a rule cannot attach to an account still provisioning.
2. Decide the purpose code with whoever owns compliance. It is reported on every conversion the rule runs, not just the first.
3. Read the agent's flag on the missing delete operation and take it to support before you design a rule-replacement flow.

## What the prompt builds

| **Endpoint** | **What the agent uses it for** |
| :- | :- |
| `GET /accounts` | Finds the account the rule attaches to |
| `POST /autoconversion-rules` | Creates the rule and returns the deposit details |
| `GET /autoconversion-rules/{id}` | Re-reads a rule's deposit details |
| `GET /autoconversion-rules` | Lists a customer's rules |
| `POST /autoconversion-rules/simulate-deposit` | Simulates a deposit in Sandbox to test matching |

## 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** |
| :- | :- | :- |
| `AUTOCONVERSION_RULE_ALREADY_EXISTS` | 409 | Customer already has an active USD, EUR, or GBP autoconversion rule. |
| `INVALID_AUTOCONVERSION_RULE` | 400 | Autoconversion rule is invalid. |
| `ACCOUNT_NOT_ACTIVE` | 409 | Account is not in a usable state. |
| `AUTOCONVERSION_RULE_NOT_FOUND` | 404 | Autoconversion rule does not exist. |

## Related resources

<CardGroup cols={2}>
  <Card title="Autoconversion rules" href="/guides/autoconversion-rules">
    Convert every deposit with a standing rule.
  </Card>

  <Card title="Accounts" href="/concepts/accounts">
    Virtual accounts, provisioning, and status.
  </Card>

  <Card title="Integrate local-currency virtual accounts" href="/prompts/integrate-virtual-accounts">
    Collect in local currency through accounts in your customer's name.
  </Card>

  <Card title="Build the BRL corridor end to end" href="/prompts/integrate-brl-corridor">
    Build BRL in over PIX and out again as working code.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.