LeadVynx is designed to protect customer information throughout its journey, from the first website message to the actions taken by your team.
A visitor asks, “Can this work across three locations?” The public assistant accepts only the fields expected for that request.
LeadVynx verifies the active website, public installation key and browser context before associating the message with a workspace.
The message is attached to one account and one website. Every related visitor, conversation and message query carries the same account boundary.
Server-side code can retrieve approved business knowledge and request an AI response without exposing private provider credentials to the browser.
An authenticated user reaches dashboard information through an active account membership. The database boundary remains in place behind the interface.
LeadVynx does not publish an automatic retention window or instant-erasure promise. Stored information follows the account relationship, applicable instructions and legal requirements.
Every account-owned record carries workspace context. Database rules and server queries use that context to keep customer records separated.
Dashboard access starts with authentication then resolves an active account membership before customer information is shown.
Private service and AI credentials remain in server code. Public errors avoid returning internal keys or message content.
Public assistant routes validate context, limit payloads and apply durable rate, idempotency and provider-budget guards.
Select a sample workspace to see the account context that travels with its records. The diagram explains the verified data model and does not show live customer data.
Tenant-owned tables include account_id and use row-level security policies based on authenticated account membership. Widget requests resolve the website account on the server before writing visitors, conversations or messages.
Each item below is tied to code, database policy or deployed application behaviour that was reviewed for this page.
Tenant-owned tables carry account identifiers and database policies check account membership.
Widget payload size, message length, identifiers and accepted fields are validated before processing.
Dashboard routes require a valid Supabase Auth user session.
Account access is derived from an active account membership and role.
Row-level security policies restrict authenticated access to account-owned rows.
Public assistant routes validate website context and the installation key before writes.
Durable rate limits, request idempotency and provider budget guards protect widget routes.
Public route errors avoid returning internal identifiers, keys or message bodies.
The service-role key and AI provider credentials are read only in server code.
Browser code receives only the public Supabase URL and anonymous key.
The deployed LeadVynx web application is served through HTTPS.
Archived knowledge remains reviewable but is excluded from visitor replies.
The public policy states retention factors without promising an unverified fixed period.
LeadVynx explains the current lifecycle without inventing an automatic retention schedule or backup deletion promise.
A visitor or account user provides information.
The service answers, qualifies or organises the relevant workflow.
Records remain attached to the account and website context.
Duration depends on the account, instructions and legal or operational needs.
Requests follow the Privacy Policy. No instant or fixed-period erasure is promised.
Share your security or data-handling questions and we will respond with the clearest information currently available.