LeakIQ technical reference

LeakIQ is designed to be safe to connect to your financial systems and straightforward to approve through an IT or InfoSec review. The key commitments:

LeakIQ is a cloud-native SaaS application deployed on Vercel's serverless infrastructure. There are no persistent application servers, each request is handled by an ephemeral serverless function that spins up on demand and is discarded after the response. This eliminates an entire class of infrastructure-level attack surface.

All routes under /operations/* enforce authentication at the layout level, unauthenticated requests are redirected to /login before any data is fetched. Workspaces with a paused subscription are redirected to the billing page before any operational data is accessible.

LeakIQ connects to your existing billing, accounting, payment and CRM systems and only ever reads from them. LeakIQ never writes back to any connected system. Each connector is individually managed, you can add, pause or remove any connection at any time.

Five native connectors are live today, Stripe, Xero, QuickBooks, Salesforce and GoCardless, alongside a generic CSV / JSON finance import that runs the same detection on an export from any other system. The remaining connectors below are in progress and are marked accordingly.

Live OAuth 2.0 connectors (Xero, Salesforce, QuickBooks) use short-lived access tokens with automatic refresh token rotation. Stripe connects through the Stripe App using OAuth, and GoCardless uses a read-only API access token, in both cases a scoped, read-only credential your team authorises and retains full control over. You can revoke access at any time by rotating or deleting the credential in the source system, LeakIQ will immediately stop making calls once it is invalid.

Removing a connection from the Connected Systems page deletes the encrypted credential immediately. LeakIQ will make no further API calls to that system.

LeakIQ runs a fixed library of deterministic revenue-leak detectors over the read-only financial records it ingests. There is no machine learning and no black box, each finding maps to one of the signals below and is surfaced with the source record attached so your team can verify it. LeakIQ does not detect tax or VAT errors, currency or FX loss, usage or metering discrepancies, and it does not read contracts or reconcile bank feeds.

Every signal above runs identically whether the data arrives from a live connector or from a CSV / JSON finance export, detection is source-agnostic. Amounts for the two pricing signals (price never moved, discount creep) are estimates, because LeakIQ observes billing history but never sees the underlying contract. Duplicate charge, duplicate invoice and duplicate credit note are surfaced as possible duplicates for a human to confirm before any refund or credit.

For an overdue UK (GBP) commercial invoice, LeakIQ also shows the statutory late-payment interest and fixed compensation you are entitled to add under the Late Payment of Commercial Debts Act, calculated from the invoice due date and the public Bank of England reference rate. This is an entitlement surfaced alongside the overdue finding, not money already lost, so it is deliberately never added to the amount at risk.

Every finding also carries a confidence score. It is deterministic, not a machine-learning probability, and reflects how directly the signal is observed in your data. A fact read straight from the ledger (an invoice that is overdue, a direct debit that failed) scores highest. A finding that needs matching (an unapplied payment, a duplicate invoice) scores a little lower. A forward-looking estimate (an expected-but-unbilled renewal, a stalled deal) lower again. Scores are capped so LeakIQ never claims total certainty, and every issue links back to the source record behind it.

LeakIQ uses a layered role-based access control model with two levels: account-level roles that govern the company (billing, users, connector setup) and workspace-level roles that govern day-to-day recovery operations. A user can belong to one or more workspaces and is assigned a workspace role independently in each, a single login carries all of a user's memberships, and switching workspace applies that workspace's role. Permission checks are enforced server-side on every request: recovery actions (execute, approve, reject and record-outcome) and all connector, user and billing changes are role-gated in the API layer, not only in the UI.

Account-level roles (company)

Workspace-level roles (per workspace)

Business email enforcement: Registration is restricted to business email addresses. Personal email domains (Gmail, Outlook, iCloud, Yahoo, Hotmail and others) are rejected at account creation before any database write occurs. This check is enforced server-side and cannot be bypassed.

Login rate limiting and account lockout: After 5 consecutive failed login attempts for a given email address, the account is locked for 15 minutes. Lockout state is stored in the database against the user record, it persists across serverless cold starts and multiple Vercel instances. Attempt counters reset to zero on the next successful authentication. Failed attempts against unknown email addresses are silently dropped.

Session tokens: Sessions are managed by NextAuth v4 using a JWT strategy. The JWT is stored in a signed, encrypted HTTP-only cookie. There is no server-side session store, tokens are stateless and self-contained. Sessions expire on an activity-based cycle.

Recovery approval governance: High-value recoveries require sign-off before they can execute, segregation of duties is enforced by the platform, not left to process. Approval authority is threshold-based and configurable per workspace: recoveries at or above the workspace's approval threshold require management approval, and those at or above the higher senior threshold require senior-management sign-off. Below the threshold no approval is required. Thresholds default to £10,000 (management) and £50,000 (senior management) and are set by Admins under Settings → Approvals. The gate is enforced server-side, an over-threshold recovery cannot execute without a recorded approval, and every approval decision is written to the append-only audit log.

Platform administrator actions: LeakIQ platform administrators have access to a set of privileged actions, listed in full below. Each one is written to the audit log of the workspace it affects, marked as a platform-administrator action, so it appears in your own audit log and audit export rather than only in ours, and is distinguishable from the same action taken by someone on your own team.

LeakIQ supports TOTP-based multi-factor authentication (RFC 6238). MFA is compatible with any standards-compliant authenticator app including Google Authenticator, Microsoft Authenticator, Authy and 1Password.

Two-factor authentication is optional and off by default; a normal sign-in remains a single step for accounts that have not enrolled. MFA status is tracked per user, and enrolment and removal are written to the audit log.

LeakIQ ingests read-only financial event data from connected systems and stores structured records for case analysis and workflow management. Data ingested is limited to what is necessary to identify and recover billing discrepancies.

What LeakIQ stores:

• Raw event records from connector syncs (invoice records, payment records, dispute records, as returned by the source system API)
• Recovery case metadata (amounts, statuses, SLA states, assigned operators)
• Approval records with timestamps and approver identity
• A full, append-only audit log of every action taken in a workspace
• Encrypted connector credentials (API keys and OAuth tokens)

What LeakIQ does not store:

• Payment card data (no PCI scope, card processing is handled entirely by Stripe)
• Bank account details or sort codes
• User passwords in plaintext (passwords are hashed with scrypt, a memory-hard key-derivation function, before storage)
• Connector credentials in plaintext (all encrypted at rest, see Security & encryption)

Data residency: Persistent data is stored in the EU (Neon PostgreSQL, AWS eu-central-1, Frankfurt). Application compute also runs in Frankfurt: Vercel serverless functions are pinned to the fra1 region, co-located with the database. Vercel Inc. and Resend are US companies, so any parent-company access is covered by Standard Contractual Clauses, but no customer data is stored on those layers and all persistent data lives in the EU database. See leakiq.io/legal/data-transfers for the full position.

Connector credentials (API keys, OAuth tokens) are encrypted before being written to the database and decrypted in-memory only when a connector call is made. The plaintext credential is never stored and never logged.

Timing-safe secret comparison: Webhook secrets (used by the inbound Zapier connector) are compared using Node.js crypto.timingSafeEqual, preventing timing-oracle attacks on secret verification.

Access boundary design: the properties below describe how access is bounded in the application. They are design properties upheld by the code paths described above, not assertions re-evaluated by a runtime check on every request:

Security event monitoring: Security-relevant events, permission denials, role and access changes, MFA enable/disable, and connector and billing changes, are recorded in the append-only, hash-chained audit trail described below, where they are queryable and exportable for review.

Every action taken in a workspace, recovery decisions, approvals, escalations, connector events, role changes, billing events, MFA changes, is written to an append-only audit log. Entries are never updated or deleted after creation.

The audit log implements a hash-chain integrity model. Each entry carries a reference to the previous entry, making retrospective tampering detectable. The full log is exportable by Admin users from the Audit & Evidence section at any time.

High-sensitivity events are written to that same append-only log: recovery workflow transitions, escalations, manual operator interventions, subscription and payment lifecycle events, role assignments and permission changes, MFA enrolment and removal, approval decisions, and privileged administrative actions.

LeakIQ processes personal data as a data processor on behalf of its customers (the data controller). Personal data processed is limited to what is contained within financial records (invoices, payments, dispute records) as returned by connected source systems.

Sub-processors: LeakIQ relies on the following sub-processors to deliver its service. Full sub-processor details, data locations and applicable data protection frameworks are included in the DPA.

LeakIQ supports federated authentication via OpenID Connect (OIDC). SSO is enabled per tenant: an explicit allowlist of approved domains is configured for your organisation, and a sign-in from any domain outside that list is refused. There is no permissive default. SSO governs authentication only. User accounts and their roles are provisioned and managed within LeakIQ, not derived from the identity provider, so a person must already have been invited into a workspace before they can sign in through your identity provider. An unrecognised account is refused rather than created.

Roles are assigned within LeakIQ and are not derived from IdP group membership. Identity provider connections are configured by LeakIQ at the platform level rather than from workspace settings.

The questions we receive most often from IT and security teams during vendor review.

The inbound connector uses a webhook rather than an outbound API call. LeakIQ generates a unique, per-workspace webhook URL, and Zapier POSTs to it when a trigger fires in your account, so LeakIQ can receive events from any of Zapier's connected apps. For the opposite direction, sending LeakIQ events out to a Zapier Catch Hook, see Settings, Webhooks in the application, which holds a per-workspace endpoint and the event types it subscribes to.

Endpoint:

POST https://api.leakiq.io/integrations/zapier/webhook?connectionId=<id>&secret=<plaintext>

Authentication:

• The connectionId is looked up and must exist as an active connection
• The stored encrypted secret is decrypted at runtime and compared to the query parameter using crypto.timingSafeEqual, preventing timing-oracle attacks
• Invalid or missing credentials return 401 Unauthorized

Accepted payload (JSON body):

{
  "eventType": "payment_failed",   // optional, defaults to "zapier_event"
  "externalId": "evt_abc123",      // optional, used for deduplication
  // any additional fields are stored as-is in the event payload
}

Successful delivery creates an event record with status RECEIVED. Events are deduplicated on (connectionId, externalId, eventType), duplicate deliveries are safely ignored. The webhook URL can be regenerated at any time from the Connected Systems page, immediately invalidating the previous secret. Failed deliveries are automatically retried (see Operational automation).

LeakIQ runs a set of scheduled background processes that drive operational workflows. All jobs are authenticated using a server-to-server bearer token (CRON_SECRET) and run on Vercel's managed cron infrastructure.

Webhook retry & dead-letter queue: Failed webhook deliveries are automatically retried on the following backoff schedule:

After maximum attempts are exhausted the delivery is dead-lettered: it is retained with its payload and last error rather than discarded, and every retry state transition is recorded in the audit log with workspace ID, entity type and last error. There is no self-serve screen for reviewing dead-lettered deliveries yet, so ask us and we will pull them for you.