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.
