How Satinash handles account data, billing records, connector metadata, synced documents, chat content, and browser-side session state.
Satinash stores the information needed to create accounts, authenticate users, run paid memberships, connect third-party providers, sync selected content into datasets, and power chat and admin workflows.
We use collected information to operate the public site and authenticated workspace, issue and verify accounts, send verification and provider-linking emails, process paid memberships, enforce plan budgets, and provide support and abuse prevention.
We also use service data to synchronize connectors, parse and index documents, generate embeddings, run cited chat responses, troubleshoot failures, publish workspace and admin updates, and maintain operational telemetry for datasets, billing, and background jobs.
Satinash uses third-party services to deliver the product. Depending on your deployment and enabled features, data may be processed by Stripe billing, identity providers, connected source providers, object storage, database and queue infrastructure, the configured parser service, and the model gateway or model providers configured for chat and embeddings.
Within the product, administrators and team owners may be able to review or manage user, billing, connector, dataset, and operational records when those controls are part of the workspace they operate.
The web client stores the current access token in browser local storage under the key `mykb_token`. The client also stores limited local state for tasks such as registration checkout recovery, membership checkout recovery, theme and timezone preferences, and debug UI state.
Satinash's own web client is designed around browser storage rather than a server-managed session cookie for authenticated API access. Third-party login and payment pages may still use their own cookies or tracking technologies under their own policies.
Conversation retention is plan-governed and user-configurable within the limits allowed by the active plan. Some plans allow a retention value of `0`, which means conversations are not automatically deleted.
Dataset and document cleanup also follows explicit product retention rules. Deleted dataset-document relation rows are retained for 4 days by default before purge, and orphaned documents and related artifacts are retained for 7 days by default before purge, unless the operator changes those backend settings.
Connector secrets are encrypted before they are stored by the application, and Satinash uses authentication, role-based access, and operational safeguards to protect service data. No system can guarantee absolute security.
You can manage some information directly inside the product, including profile details, linked sign-in methods, passwords, plan changes, conversation retention, datasets, and conversations you choose to delete.
Depending on your location and how the deployment is operated, you may also have legal rights to request access, correction, deletion, restriction, or export of personal data. Because Satinash can be operator-managed, privacy requests may need to be handled by your workspace administrator or the support contact shown in the deployment.
Satinash can be deployed with external infrastructure and providers in different jurisdictions. As a result, your data may be processed in the United States or other locations where the operator's hosting, storage, identity, payment, parser, or model providers run their services.
By using the service and enabling integrations, you instruct Satinash to make the transfers needed to authenticate you, process payments, sync connected content, and generate model-backed responses.
Satinash is built for workplace and business use and is not directed to children. We do not knowingly collect personal data from children through the service.
This Privacy Policy may change as the service, integrations, or legal obligations evolve. The effective date above reflects the latest posted version.
For privacy questions or requests, contact the workspace operator, your account administrator, or the support contact exposed by the deployment in account or invoice surfaces when available.