> ## 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. # Audit an existing Lumx integration > A copy-paste prompt that audits live Lumx code for what costs money — duplicate payments, unverified events, message matching, undisclosed parties. Paste this prompt into your coding agent to audit an integration that already runs, including one you inherited. The agent reviews a live integration for duplicate-payment risk, unverified events, fragile error handling, compliance gaps, and enum drift, and ranks what it finds. ## Before you start * Access to the integration's code, including webhook handlers and batch jobs. ## Prompt ```text Prompt theme={null} You are a senior engineer auditing a live Lumx integration. Find what will cost money or fail a compliance review, and rank by that, not by code style. Ground truth. Read both before writing any findings 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. Enum and required-field claims come from here. Audit these seven, each against the sources, and cite file and line for every finding. 1. Duplicate payment risk. Every money-moving POST needs an Idempotency-Key generated once, persisted before the call, and reused on retry. A key minted inside a retry loop is the same as no key. Keys expire after 24 hours, so a retry a day later is a new payment. 2. Event trust. Webhook handlers must verify the signature over the raw body, strip the whsec_ prefix before decoding, accept any valid signature in the header, and deduplicate on webhook-id. Any handler acting on an unverified payload is a finding, not a style note. 3. Error matching. Handlers must branch on code, not on message — the message is explicitly subject to change and is generic on every 5xx. Any string comparison against a message is a finding. 4. Undisclosed parties. Read /compliance/nested-payments and check the money flow, not the code: every transaction must be the onboarded customer's own funds paying its own counterparty. Pooling, sub-balances used to track other parties, or payouts to parties nobody onboarded are compliance findings and outrank everything above. 5. Holder relationship and purpose. Each destination carries a holder.relationship from a closed enum and each transaction a purpose from a closed enum, and they have to be true rather than defaulted. PERSONAL_ACCOUNT is valid only with a SELF destination. 6. Limits awareness. Read GET /customers/{id}?includeTransactionLimits=true and check the code handles a rejected transaction from a hit limit as a business state, not an exception. 7. Pagination and drift. Every list read — GET /customers, GET /transactions, GET /destinations, GET /accounts, GET /customers/{id}/limit-requests, GET /autoconversion-rules — needs size and cursor. Then compare the enums hardcoded in the codebase against the spec today and report each one that has drifted. Constraints: - Do not fix anything. Findings only. A wrong automated fix in a money path is worse than the finding. - Do not state a rate limit. None is published and the spec declares no 429 response. Check only that retries back off. - Where the spec and the prose disagree, report both and say which one the code followed. Deliverables: - Findings ranked by money and compliance exposure, each with file, line and the source that makes it a finding. - The list of hardcoded enums that have drifted from the spec. - The questions only Lumx can answer, and what each one blocks. ``` ## How to use 1. Point the agent at the whole integration, including the webhook handler and any batch job — the findings that matter are usually in the job nobody has read for a year. 2. Take finding class 4 to whoever owns compliance before you touch code. It is a business-model question, not a bug. 3. Re-run after fixing. Drifted enums come back every time the API adds a value. ## What the prompt builds | **Endpoint** | **What the agent uses it for** | | :- | :- | | `GET /customers/{id}` | Checks how the code reads transaction limits | | `GET /customers` | Checks pagination | | `GET /transactions` | Checks pagination | | `GET /destinations` | Checks pagination | | `GET /accounts` | Checks pagination | | `GET /customers/{id}/limit-requests` | Checks pagination | | `GET /autoconversion-rules` | Checks pagination | ## 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** | | :- | :- | :- | | `IDEMPOTENCY_KEY_CONFLICT` | 409 | Same `Idempotency-Key` reused with a different body. | | `TRANSACTION_LIMIT_EXCEEDED` | 422 | Exceeds the customer's single, daily, or monthly limit. | | `PERSONAL_ACCOUNT_RELATIONSHIP_REQUIRED` | 400 | Personal transactions require a `SELF` bank account. | | `TOO_MANY_REQUESTS` | 429 | Rate limit exceeded. | ## Related resources Safe retries with Idempotency-Key. Whose funds can move, and for whom. Audit a working Sandbox integration before real money moves. Find out why webhooks don't arrive or fail verification. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.