Technical documentation
LeakIQ technical reference
This document is for engineering, IT, security, data, compliance and legal teams conducting pre-procurement evaluation of LeakIQ. It covers how the platform is built, how data flows through it, how credentials are protected, and how LeakIQ meets enterprise security and regulatory requirements.
For questions not answered here — including security questionnaire completion, data processing agreements or architecture review calls — contact support@leakiq.io.
Security posture
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:
Read-only connectors. No write-back.
LeakIQ connects using read-only credentials. We surface gaps — we never create, update or delete records in any connected system.
AES-256-GCM credential encryption
All connector credentials are encrypted before storage. The encryption key is held separately from the database and is never logged or returned in API responses.
Workspace isolation
Every workspace has a separate data partition. Workspace IDs are scoped to every database query — cross-tenant data access is structurally impossible at the ORM layer.
Three-tier RBAC
Viewer, Operator and Admin roles with server-side enforcement. Role changes are audit-logged. There is no client-side permission gating.
Tamper-evident audit log
Every action is written to an append-only log with actor identity and timestamp. The log implements a hash-chain integrity model — retrospective tampering is detectable.
GDPR compliant
Data is stored in the EU (Neon PostgreSQL, AWS eu-west-1, Ireland). LeakIQ acts as a data processor. A signed Data Processing Agreement is available on request.
Authentication & session security
Sessions are signed with a rotating HMAC secret and stored in HTTP-only cookies. Passwords are bcrypt-hashed. MFA is available for all workspace members.
Data retention & deletion
Data is retained for the workspace subscription lifetime. Deleting a connection removes its encrypted credentials immediately. Full workspace deletion purges all records.
Architecture
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.
| Layer | Technology | Notes |
|---|---|---|
| Frontend & API | Next.js 15 App Router | React Server Components; server actions for mutations |
| Deployment | Vercel (serverless) | No persistent servers; ephemeral per-request execution |
| Database | Neon PostgreSQL 16 | Managed serverless Postgres; connection pooled |
| ORM | Prisma 5 | Type-safe query builder; no raw SQL in application code |
| Session management | NextAuth v4 — JWT strategy | Sessions in signed, encrypted HTTP-only cookies only |
| Email delivery | Resend | Transactional email only; no marketing email |
| Billing | Stripe | Subscription management; no card data touches LeakIQ servers |
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.
Connectors
LeakIQ connects to your existing billing, accounting, payment and CRM systems using read-only credentials. LeakIQ never writes back to any connected system. Each connector is individually managed — you can add, pause or remove any connection at any time.
| Connector | Category | Auth method | Data LeakIQ reads (read-only) |
|---|---|---|---|
| Stripe | Billing & payments | API key (restricted, read-only) | Charges, payment intents, disputes, subscriptions |
| Xero | Accounting | OAuth 2.0 | Invoices, credit notes, payments, bank transactions |
| NetSuite | ERP & finance | Token-based auth (TBA) | AR invoices, customer payments, billing variances |
| Salesforce | CRM | OAuth 2.0 | Opportunities, renewals, account billing activity |
| HubSpot | CRM | OAuth 2.0 | Deals, contacts, renewal activity, pipeline events |
| QuickBooks Online | Accounting | OAuth 2.0 | Invoices, payments, credit memos, AR ageing |
| GoCardless | Direct debit | API key | Mandates, payments, payment failures |
| Chargebee | Subscription billing | API key | Subscriptions, invoices, dunning events |
| Zuora | Subscription billing | API key | Billing runs, usage records, invoice items |
| Sage Intacct | ERP & finance | API key | AR invoices, payments, multi-entity billing |
| Braintree | Payments | API key | Transactions, disputes, chargebacks |
| Zapier | Automation / webhook | Webhook secret (timing-safe verified) | Any event payload from Zapier-connected apps |
OAuth 2.0 connectors (Xero, Salesforce, HubSpot, QuickBooks) use short-lived access tokens with automatic refresh token rotation. API key connectors (Stripe, GoCardless, Chargebee, Zuora, Sage Intacct, Braintree) require a read-only or restricted key that your team generates and retains full control over. You can revoke access at any time by rotating or deleting the key in the source system — LeakIQ will immediately stop making calls once the credential 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.
Authentication & access control
LeakIQ uses a three-tier role-based access control model. A user can belong to one or more workspaces and is assigned a role independently in each workspace — 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.
| Role | Capabilities |
|---|---|
| Viewer | Read-only access to recovery cases, queues and reports. Cannot take actions or change any settings. |
| Operator | Can triage, progress and close recovery cases. Cannot manage connectors, users or billing. |
| Admin | Full access including connector management, member management, billing and audit log export. |
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.
| Property | Detail |
|---|---|
| Lockout threshold | 5 consecutive failed login attempts for the same email address |
| Lockout duration | 15 minutes from the time the 5th failure is recorded |
| Lockout scope | Per email address — not per IP address |
| Persistence | DB-backed (User.lockedUntil) — survives serverless restarts |
| Reset condition | Successful authentication clears the counter and removes any lockout |
| Admin unlock | Platform administrators can unlock accounts immediately from the platform-admin Users panel |
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 Manager approval, and those at or above the higher Director threshold require Director-level sign-off. Below the threshold no approval is required. Thresholds default to £10,000 (Manager) and £50,000 (Director) 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 immutable audit lineage as a governance event.
Platform administrator actions: LeakIQ platform administrators have access to a set of privileged user management actions, each of which is written to the audit log.
| Admin action | What it does | Audit classification |
|---|---|---|
| Unlock account | Immediately clears a rate-limit lockout and resets the failed attempt counter | ADMIN_ACTION |
| Send password reset | Generates a signed HMAC recovery token (1-hour expiry) and delivers a password reset link to the user's registered email address | ADMIN_ACTION |
| Suspend workspace | Sets client status to SUSPENDED — workspace remains accessible but is flagged for review | ADMIN_ACTION |
| Reactivate workspace | Restores client status to ACTIVE | ADMIN_ACTION |
| Delete client | Permanently removes a client with no attached workspaces | ADMIN_ACTION |
Multi-factor authentication
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.
| Property | Detail |
|---|---|
| Protocol | TOTP — RFC 6238 (Time-based One-Time Password) |
| Token length | 6 digits, 30-second window |
| Enrolment | QR code scan or manual secret entry in authenticator app |
| Backup codes | 8 single-use recovery codes generated at enrolment |
| Workspace enforcement | MFA can be mandated for all members by Admins |
| Audit events | MFA_CHALLENGE and MFA_EVENT written to immutable audit lineage |
MFA status is tracked per user and enforcement policy is set per workspace. All MFA lifecycle events (enrolment, verification, removal, failed challenges) are written to the security event log and are visible to Admin users in the Audit & Evidence section of the platform.
Data handling
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 within the platform
- 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 bcrypt before storage)
- Connector credentials in plaintext (all encrypted at rest — see Security & encryption)
workspaceId filter enforced at the ORM layer. It is architecturally impossible for one workspace's data to appear in another workspace's query. There is no shared data pool between tenants.| Data category | Where stored | Retention |
|---|---|---|
| Connector event records | Neon PostgreSQL (RawIntegrationEvent) | Retained for the lifetime of the active connection |
| Recovery cases & queue items | Neon PostgreSQL | Retained for workspace lifetime |
| Audit log | Neon PostgreSQL (AuditLog) | Retained indefinitely; append-only |
| Connector credentials | Neon PostgreSQL (IntegrationCredential, encrypted) | Deleted immediately on connection removal |
| Session tokens | Signed/encrypted HTTP-only cookie (client-side only) | Expiry-bounded; no server-side copy exists |
Data residency: The default database region is EU (Neon PostgreSQL, AWS eu-west-1, Ireland). Vercel serverless functions run across edge regions for latency purposes; no customer data is cached at edge nodes — all persistent data lives in the database. Alternative database regions are available on request for Enterprise customers.
Security & encryption
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.
| Property | Detail |
|---|---|
| Encryption algorithm | AES-256-GCM (authenticated encryption with associated data) |
| IV | 12-byte cryptographically random IV, generated per encryption operation |
| Authentication tag | 16-byte GCM auth tag verified on every decryption — tampered or corrupted ciphertext is rejected |
| Key derivation | SHA-256 hash of CONNECTOR_CREDENTIAL_SECRET environment variable |
| Storage format | base64(IV) · base64(authTag) · base64(ciphertext) stored as a single field |
| Transport encryption | TLS 1.2+ enforced by Vercel on all connections (inbound and outbound) |
Timing-safe secret comparison: Webhook secrets (used by the Zapier connector) are compared using Node.js crypto.timingSafeEqual, preventing timing-oracle attacks on secret verification.
Runtime access boundary enforcement: LeakIQ asserts the following access boundary properties on each request cycle:
| Boundary | State |
|---|---|
| Workspace isolation enforced | Yes — all queries scoped to workspaceId at ORM level |
| Runtime isolation enforced | Yes — no shared runtime state across workspaces |
| Cross-workspace data access | Blocked — enforced at both ORM and application layer |
| Replay execution | Disabled |
| Distributed cross-workspace coordination | Disabled |
Security event monitoring: The platform maintains a structured security event log with the following typed events, each classified by severity (INFO / WARNING / CRITICAL):
| Security event type | What it captures |
|---|---|
| FAILED_AUTHENTICATION | Failed login attempts |
| RBAC_VIOLATION | Requests that exceed the requesting user's role permissions |
| MFA_CHALLENGE | MFA verification attempts (pass and fail) |
| PRIVILEGED_REAUTH | Re-authentication requests for sensitive actions |
| SSO_CONFIGURATION_CHANGE | Changes to identity provider settings |
| SECRET_ROTATION_EVENT | Connector credential rotation events |
| ENVIRONMENT_GOVERNANCE_EVENT | Runtime environment validation outcomes |
Audit trail
Every action taken within LeakIQ — 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.
| Field | Description |
|---|---|
| event | Machine-readable event name (e.g. recovery.case.approved, queue.item_auto_assigned) |
| entityType | The type of entity the event relates to (e.g. RecoveryCase, Workspace) |
| entityId | The ID of the entity |
| userId | The user who performed the action (null for system-generated events) |
| metadata | JSON payload with event-specific context |
| createdAt | UTC timestamp, immutable after write |
In addition to the operational audit log, an immutable audit lineage layer records high-sensitivity events across the following typed categories:
| Lineage event type | What it covers |
|---|---|
| WORKFLOW_TRANSITION | Recovery workflow state changes |
| ESCALATION_EVENT | SLA breach and escalation triggers |
| INTERVENTION_EVENT | Manual operator interventions |
| BILLING_EVENT | Subscription, payment and invoice lifecycle |
| RBAC_CHANGE | Role assignments and permission changes |
| SSO_CHANGE | Identity provider configuration changes |
| MFA_EVENT | MFA enrolment, verification and removal |
| ROLL_OUT_APPROVAL | Governance approval decisions |
| ADMIN_ACTION | Privileged administrative actions |
GDPR & data privacy
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.
| Topic | LeakIQ position |
|---|---|
| Data controller | LeakIQ's customer (the workspace owner) |
| Data processor | LeakIQ |
| Lawful basis | Contractual necessity / legitimate interests (revenue recovery operations) |
| Data subjects | Your customers whose billing records are being reconciled |
| Right to erasure | Supported — submit a deletion request to support@leakiq.io |
| Data portability | Audit log and case data exportable by Admin users at any time |
| Data Processing Agreement (DPA) | Available on request — contact support@leakiq.io |
| UK GDPR | Applicable — LeakIQ operates as a UK-based service |
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.
| Sub-processor | Role | Data handled |
|---|---|---|
| Vercel | Application hosting & serverless runtime | Request metadata; no persistent customer data stored |
| Neon | Database (PostgreSQL) | All persistent workspace and customer data |
| Resend | Transactional email delivery | Recipient email address and notification content |
| Stripe | Billing & payment processing | Subscription and billing data only; no revenue recovery data |
Enterprise SSO
LeakIQ supports federated authentication via industry-standard identity protocols. SSO is configured at workspace level. Users authenticating via SSO are matched by email domain and are subject to the same three-tier RBAC model as password-based accounts.
| Provider | Protocol | Availability |
|---|---|---|
| Google Workspace | OAuth 2.0 / OIDC | Available |
| Microsoft Azure AD / Entra ID | OAuth 2.0 / OIDC | Available |
| SAML 2.0 (any compatible IdP) | SAML | Available on request |
Role assignment after SSO login is managed within LeakIQ and is not derived from IdP group membership by default. IdP group-to-role mapping is available for Enterprise customers on request. All SSO configuration changes are classified as SSO_CHANGE events and written to the immutable audit lineage log.
InfoSec Q&A
The questions we receive most often from IT and security teams during vendor review.
Do you store our financial data?
We store the minimum data needed to detect and surface revenue gaps: metric snapshots, event records, and derived issues. We do not store raw payment card data. All data is associated with your workspace and deleted when the workspace is closed.
Can you write to our systems?
No. All connectors are read-only. LeakIQ does not send requests that create, update or delete records in any connected source system.
How are credentials protected?
Credentials are encrypted with AES-256-GCM using a secret key that is stored separately from the database. Credentials are never returned in API responses or written to logs. The encryption key can be rotated without a data migration.
Where is data stored?
In the EU — Neon PostgreSQL on AWS eu-west-1 (Ireland). Vercel serverless compute runs across edge regions for latency; no customer data is cached at edge nodes. Alternative database regions are available for Enterprise customers on request.
Do you offer a DPA?
Yes. Contact security@leakiq.io and we will provide a signed Data Processing Agreement within two business days.
Are you SOC 2 certified?
We are working towards SOC 2 Type II. Our infrastructure providers (Vercel, Neon, AWS) are SOC 2 certified. Contact us for our current security posture documentation.
How do we revoke access?
Disconnect a connector from the Connected Systems page at any time — this immediately invalidates the credential and stops all API calls. Closing the workspace purges all data.
What happens if LeakIQ is compromised?
We follow a documented Incident Response Plan covering detection, triage, containment, eradication, recovery and notification. Affected customers are notified without undue delay — and in any event within 72 hours of confirming a personal data breach — by email, with the information they need to meet their own regulatory obligations.
Can we get a penetration test report?
We conduct an annual independent penetration test; the next is scheduled for 14 June 2027. The executive summary is available under NDA — contact security@leakiq.io.
How do we conduct a security review before connecting?
Start with the Security posture section above and this Q&A. For deeper review, email security@leakiq.io — we can schedule a technical call with your InfoSec team and complete your security questionnaire.
Zapier webhook connector
https://api.leakiq.io. Requests to api.leakiq.io/<path> map directly to the corresponding API route — no additional prefix required.The Zapier connector uses an inbound webhook rather than an outbound API call. LeakIQ generates a unique, per-workspace webhook URL. Zapier POSTs to this URL when a trigger fires in your account, enabling LeakIQ to receive events from any of Zapier's 7,000+ connected apps.
Endpoint:
POST https://api.leakiq.io/integrations/zapier/webhook?connectionId=<id>&secret=<plaintext>
Authentication:
- The
connectionIdis 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).
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.
| Process | Schedule | What it does |
|---|---|---|
| Issue auto-assignment | Every 15 minutes | Assigns unassigned open queue items to Operator/Admin members using workload-balanced round-robin (fewest open items first) |
| First-detection notification | Hourly | Fires once per workspace after the first connector sync that surfaces at least one revenue issue; sends a detection summary email to the workspace Admin. Idempotent — skips if already sent (Workspace.firstDetectionEmailSentAt is set) |
| Escalation notification | Daily at 08:00 | Emails workspace Admins when queue items are at-risk or breached SLA; marks associated workflows as escalated |
| Approval reminder | Daily at 09:00 | Sends reminder emails for pending approvals at 48-hour (amber) and 7-day (red) thresholds |
| Payment dunning | Daily at 09:00 | Emails workspace Admins at day 3 and day 7 of a payment failure; skips if payment has since succeeded |
| Trial expiry warning | Daily at 08:00 | Sends warning emails at 7 days and 3 days before trial expiry (24-hour final warning sent 12–36 hours before expiry) |
| Inactivity re-engagement | Daily at 09:00 UTC | Emails trial workspace Admins when no AuditLog activity has been recorded in the past 7 days. Idempotent within the deduplication window |
| NPS pulse | Daily at 10:00 UTC | Sends a single-question Net Promoter Score email to workspaces that are 21–28 days old (mid-trial for 30-day pilots). Responses are recorded at /api/nps. Fires once per workspace |
| Monthly reconciliation summary | 1st of month at 07:00 | Emails Growth and Enterprise workspace Admins a prior-month summary: issues detected, resolved, open and total exposure |
| Webhook retry | Every 10 minutes | Retries failed webhook deliveries with exponential backoff |
| Connector health alert | Hourly | Checks connector health; alerts Admins if a connector is degraded or unreachable |
Webhook retry & dead-letter queue: Failed webhook deliveries are automatically retried on the following backoff schedule:
| Attempt | Delay |
|---|---|
| First delivery | Immediate |
| Retry 1 | 5 minutes |
| Retry 2 | 30 minutes |
| Retry 3 (max) | 2 hours |
After maximum attempts are exhausted, the item is moved to a dead-letter queue for manual review by workspace Admins. All retry state transitions are recorded in the audit log with workspace ID, entity type and last error.
Have a security or technical review question?
We're happy to complete security questionnaires, provide a Data Processing Agreement, supply additional architecture detail, or join a technical review call before you connect your systems.