Trust Center
Every price and product claim is recorded, hash-chained, and exportable.
We do not claim the shopping agent never makes a mistake. We claim something provable instead: every price, stock, delivery, and policy claim it makes to a shopper is written to a tamper-evident ledger alongside the catalog data it came from, and any merchant can export that evidence for a specific conversation in seconds if a claim is ever disputed.
Mechanism
The tamper-evident claims ledger
Every time the shopping agent states a price, stock level, delivery estimate, or policy detail, that claim is written to an append-only, per-tenant, hash-chained record alongside the exact catalog snapshot it was derived from. Each record's hash incorporates the previous record's hash, so any alteration after the fact breaks the chain and is detectable.
If the agent's own real-time guard strips a proposed product reference because it does not match your catalog, that strip event is recorded too: what was proposed, what was removed, and why.
From your dashboard, you can browse the ledger, verify chain integrity on demand, and export a complete dispute evidence pack for any conversation thread: the transcript, every claim made, the catalog ground truth behind each one, and any order that resulted. Export as JSON for system integration, or CSV for a payment processor or shopper dispute.
If a ledger write ever fails (a database outage, for example), that gap window is recorded and surfaced honestly in the export rather than silently dropped.
Security posture
How we isolate and protect your data
Row-level tenant isolation
Every table is scoped by PostgreSQL row-level security to a tenant ID. No application query can return data across tenant boundaries.
Hashed API keys
Widget API keys are stored one-way hashed. The plaintext key is shown once, at creation, and never again.
HMAC-verified webhooks
Inbound WooCommerce and Shopify webhooks are HMAC-signature verified before being enqueued for processing.
Encrypted credentials at rest
WhatsApp Business access tokens are encrypted with AES-256-GCM before storage; the plaintext token is never persisted.
Subprocessors
Who processes data on our behalf
We use the following subprocessors to deliver the platform. Each is bound by a data processing agreement appropriate to its role. We do not share your data with advertising networks, and we do not sell your data.
AI inference
Anthropic
LLM inference for the shopping agent and GEO hallucination sweeps.
Data: Query text and relevant catalog context sent per-request; no persistent identifiers.
OpenAI
Fallback LLM inference and embedding generation for catalog retrieval.
Data: Query text, catalog context, and product content sent for embedding; no persistent identifiers.
Google (Gemini)
Fallback LLM inference and GEO citation benchmarking.
Data: Query text and relevant catalog context sent per-request; no persistent identifiers.
Infrastructure
Supabase
PostgreSQL database hosting with row-level security enforced per tenant.
Data: All persisted platform data: account, catalog, conversation, and billing records.
Redis
Job queue (BullMQ) and short-lived caching for rate limits and session state.
Data: Queue payloads and cache entries; short-lived, not a system of record.
Payments
Paddle
Merchant of Record for subscription billing and invoicing.
Data: Billing contact details and subscription state; payment card data is held by Paddle, never by VritantAI.
Razorpay
Payment link generation and reconciliation for native-checkout orders.
Data: Order amount, currency, and payment status; card data is held by Razorpay, never by VritantAI.
Messaging
Meta (WhatsApp Business Platform)
Sending and receiving WhatsApp messages on a tenant's behalf via the Embedded Signup OAuth flow.
Data: WhatsApp Business Account ID, phone number ID, and an encrypted access token; message content in transit.
Observability
Sentry
Error monitoring across the API, workers, and dashboard.
Data: Stack traces and request metadata; scrubbed of known-sensitive fields before capture.
PostHog
Product analytics for the widget and dashboard.
Data: Anonymised usage events; not used for advertising or cross-site tracking.
Data processing
Data processing summary
We do not train AI models on your data. Your catalog data and shopper conversation data are used only to answer that conversation and to power your own dashboard analytics. They are never used to train or fine-tune any AI model, ours or a third party's.
Conversation logs default to a 12-month retention window, configurable to a shorter period in account settings. Audit history is retained for 24 months.
A merchant, shopper, or their representative can request data access, correction, export, or deletion. Full details, including how we handle GDPR and India's DPDP Act, are in our Privacy Policy. A data processing agreement is available on request for enterprise customers: email business@vritantai.com.
Reliability
Uptime and incident communication
Our target for the dashboard and API is 99.9% monthly uptime, excluding scheduled maintenance windows, which we announce in advance by email and in-app notification.
Every shopper request carries a trace ID that we can follow across the API gateway, the shopping agent, and background workers, so an incident is diagnosed against a specific request rather than by timestamp guesswork.
During an incident we post updates so you can tell whether an issue is on your end or ours before opening a support ticket. A public, independently-hosted status page is on our near-term roadmap; until it ships, email business@vritantai.com any time for the current status of your account and we will respond directly.
Security vulnerability disclosures: email business@vritantai.com and we will respond promptly. We do not publish a bug bounty program at this time.