Trust Center

Security, privacy, and operational transparency for buyers who verify.

Trust summary

Truthful by design

LeadIntel stores the minimum needed to run the service.

Authentication is handled through secure infrastructure.

Billing is handled by Stripe.

Workspace data is access-controlled and tenant-isolated.

Public and authenticated routes are rate-limited.

Secrets remain server-side.

What larger teams usually ask about

Buyer readiness
These questions map to how LeadIntel actually works in production: workspace isolation, access controls, and action delivery.
  • What data is stored, and what is explicitly out of scope?
  • What first-party intent/visitor signals exist, and how are they scoped to a workspace?
  • How is tenant/workspace access controlled?
  • What audit visibility exists for team-governed workflows?
  • How do exports and webhooks behave (and what is sent)?
  • How are secrets handled (where do API keys live)?
  • What rate limiting and abuse protections exist on public and auth routes?
  • How can we request deletion or support escalation?
  • What does LeadIntel not claim yet (so we don’t assume it)?

Current trust posture

No overclaims
What’s in place today:
  • Workspace (tenant) isolation and access-controlled data boundaries.
  • Row-level security policies for user/workspace-scoped access.
  • Server-side secret handling (no client exposure of private keys).
  • Rate limiting on public and authenticated routes.
  • Structured logging and request IDs for debuggability.
  • Stripe for billing; Supabase for authentication and database.
  • Webhook + export actions designed for operational handoff.
  • Audit visibility for key team-governed actions (templates/approvals and operational handoff surfaces).
What we do not claim:
  • SOC 2 / ISO 27001 certifications unless explicitly stated.
  • SSO/SAML/SCIM as generally available features.

Operational boundaries

  • LeadIntel is not a general-purpose contact database.
  • People and buying-group surfaces are persona-level recommendations (heuristic, signal-based).
  • First-party intent appears only when a match exists; when it doesn’t, the product shows a premium empty state.
  • When source coverage is thin, the product says so directly in the UI.
  • Support and deletion requests route through the published support contact path.
For larger deployments, use the Trust Center docs and contact us to align on rollout requirements and current control scope.

Operational transparency

Inspectable
Freshness
Freshness matters (and we show it)
Signal-driven outputs are strongest when supporting events are recent. When signals are stale or missing, LeadIntel surfaces “limited” states instead of guessing.
Coverage
Coverage is inspectable, not implied
Account and report views summarize source coverage and limitations (signals, first-party matches when available, and explainability completeness).
Auditability
Operational actions are logged
Workspace-governed actions like exports, webhooks, templates, briefs, and key generations are recorded as metadata-first audit events (no sensitive bodies).
Handoffs
Integrations are honest and destination-based
LeadIntel prepares CRM and sequencer-ready handoff packages and delivers them via workspace-configured webhooks/exports. Delivery history is sanitized and inspectable.

Security

Privacy

Terms

Acceptable Use

Subprocessors

DPA

Buyer readiness

Controls today, and what we do not claim.
Open

Status

Version

Changelog

Roadmap