> ## 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. # Set up partner fees and revenue share > A copy-paste prompt that configures a Lumx partner fee, applies it correctly on locked and floating rates, and proves collection in sandbox first. Paste this prompt into your coding agent to take a cut of every transaction you route through Lumx. The agent creates the fee, applies it to locked and floating rates, shows customers the final numbers, and reconciles what was collected in Sandbox. ## Before you start * A Sandbox API key. See [Authentication](/get-started/authentication). * A wallet you control to receive the fees. ## Prompt ```text Prompt theme={null} You are a senior backend engineer configuring Lumx partner fees so the platform earns on each transaction it routes, and wiring them into the existing payment paths. Ground truth. Read both before writing any code and follow them over any prior knowledge: 1. https://docs.lumx.io/concepts/partner-fees — what the fee is, how it is applied and where it is paid. Also read https://docs.lumx.io/llms.txt for the documentation index. 2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec. The request body is smaller than the prose suggests; build from the spec. Work against sandbox at https://api-sandbox.lumx.io with a server-side key. 1. Read the PartnerFeeRequest schema in the spec before writing the payload. It takes exactly name, walletAddress and fees, with fees.onRamp and fees.offRamp each holding rate and flatAmount. Send nothing else. If the prose mentions a field the schema does not define, flag it and leave it out. 2. Decide the wallet that receives the fees. It can be your own treasury address or a wallet Lumx provisions by onboarding your own entity as a customer. Supported networks are EVM chains, Tron and Stellar. 3. Create the fee with POST /partner-fees. rate is in basis points, so 75 bps is 0.75 percent; flatAmount is a fixed amount per transaction. Keep the returned id — every transaction references it. 4. Apply it in the right place, which depends on the rate type: with a locked rate, pass partnerFeeId on POST /exchange-rates so the fee is inside the quote the customer sees; with a floating rate, pass it on the transaction instead. 5. Read the locked-rate response and show your customer the real numbers. It breaks fees into the Lumx share, the partner share and the total, and gives baseTargetAmount, finalTargetAmount and finalExchangeRate. Display the final values, not the base ones. 6. Verify collection in sandbox: run one POST /transactions/on-ramp with the fee applied, then read GET /partner-fees/{id} and the transaction receipt and reconcile what was charged against what you configured. Constraints: - Do not assume a default-fee flag exists in the API. The prose describes marking a fee as default; the request and response schemas in the spec do not carry that field. Pass partnerFeeId explicitly on every call and report the gap. - The request schema gives the unit for flatAmount only on the off-ramp side, while the response schema and the prose state dollars for both. Treat flatAmount as dollars on both sides and verify with one sandbox transaction before charging. - Do not state a rate limit while listing fees with GET /partner-fees. None is published. Handle 429 TOO_MANY_REQUESTS with exponential backoff. Deliverables: - The fee configuration, with the bps and flat values written down in the code as a decision. - Both application paths wired, locked and floating, with a test each. - A sandbox reconciliation showing configured versus collected. ``` ## How to use 1. Decide the rate with whoever owns pricing before running this. It is the one input the agent cannot infer, and it ends up in every quote. 2. Use a wallet you control on a network you can actually monitor — fees land there and nowhere else. 3. Check the two flagged gaps in the agent's report with Lumx before go-live, especially the missing default-fee field if your design assumed it. ## What the prompt builds | **Endpoint** | **What the agent uses it for** | | :- | :- | | `POST /partner-fees` | Creates the fee | | `GET /partner-fees` | Lists your fees | | `GET /partner-fees/{id}` | Reads a fee to reconcile what was charged | | `POST /exchange-rates` | Applies the fee inside a locked quote | | `POST /transactions/on-ramp` | Applies the fee on a floating-rate transaction | ## 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** | | :- | :- | :- | | `PARTNER_FEE_NOT_FOUND` | 404 | Partner fee does not exist. | | `INVALID_WALLET_ADDRESS` | 400 | Partner wallet address is invalid for the blockchain. | | `EXCHANGE_RATE_EXPIRED` | 422 | Locked rate has expired. | ## Related resources Fee structure and when fees apply. Locked and floating quotes. Pay marketplace sellers and take a platform fee on every sale. Take fiat in and deliver stablecoin to the customer's wallet. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.