How Lystiva handles your data.

1. Scope

This page describes the data Lystiva processes when you visit the public site, create an account, use a workspace, upload product or artwork material, create Studio work, prepare destination exports, or use billing.

Lystiva is workspace-scoped. The server checks the authenticated identity and workspace membership before protected data is read or changed. Client-supplied IDs are selectors, not permission to access another workspace.

2. Account and authentication data

For an account, Lystiva and its authentication component process information such as your email address, display name, authentication identity, password credential data, email-verification state, sessions, and security or rate-limit records needed to sign you in, verify your email, recover access, and protect the service.

The application keeps its account and workspace identity linked to the Better Auth identity that authenticated the request. Authentication secrets and session authority remain server-side; they are not exposed as durable client data.

3. Workspace and product data

When you use Lystiva, the service can process workspace membership and lifecycle state, canonical Sources, uploaded product or artwork files, file checksums and evidence roles, seller-confirmed facts and review decisions, targeted evidence requests, Visual Jobs, generation plans and prompts, reusable Person, Scene, Look, or Brand revisions, generated image versions, reviews, Collections, listing copy, Listing Intents, destination exports, and related activity or audit records.

Private uploaded and generated bytes are stored through the application's private binary-object and R2 storage boundary. Raw object keys, provider URLs, and signed delivery URLs are not treated as client authority. Signed reads are short-lived and each file sink rechecks the live workspace and parent lineage.

Lystiva does not treat an AI proposal as a seller-confirmed fact. Source analysis, generation planning, image generation, reviews, and listing copy preserve the state needed to show what was proposed, accepted, rejected, or still needs attention.

4. Billing and destination export data

If you subscribe, buy a top-up, or use credits, the service processes application billing and credit state such as plan, credit grants, reservations, consumption, payment-provider customer or subscription identifiers, orders, refunds, webhook events, and reconciliation records. Polar is the configured billing provider; payment credentials are handled by the payment flow rather than stored as raw card data in the application.

Destination exports contain the reviewed Source-owned assets and listing copy you choose to prepare. Export artifacts remain workspace-scoped until you download them; you decide whether and where to upload them.

5. AI and service providers

Lystiva uses service providers to operate specific features. Convex hosts durable application state and backend functions. Cloudflare R2 stores private Source, Studio, and export bytes. Resend sends authentication email and manages the optional marketing contact list. Polar processes subscription and payment events. PostHog processes optional usage analytics and sanitized browser error reports when you permit them.

OpenRouter and the configured underlying text or vision model receive the bounded data needed for Source analysis, generation planning, or listing copy when you request those features. fal receives the authorized image inputs and prompts needed for new generation through the GPT Image 2.5 Sunburst Edit transport. Pre-cutover requests retain their original provider identity for lookup-only recovery. Provider retention and handling are also governed by the provider terms and configuration in effect for the request; do not upload material you are not permitted to send to a provider.

The service applies its current provider, data-collection, zero-data-retention, runtime, storage, and capability gates, but a gate in Lystiva is not a promise that an independent provider has no separate retention or legal obligations.

6. Optional analytics and browser error reporting

Necessary authentication and application behavior can use cookies, including the session required to keep you signed in. Cookie preferences lets you independently allow Usage analytics and Error reporting, or choose Accept all or Reject optional in the notice. Necessary technologies are always on. We store your choices in browser local storage for 30 days. The PostHog client starts only when at least one optional category is allowed. A missing or expired choice, rejection of both categories, or unavailable browser storage prevents new optional collection. Development runtimes and local browser hosts, including local production-build previews, do not initialize the client, collect attribution, or show the consent controls. Hosted staging and production use the same preference gates.

If you allow Usage analytics, we send selected page, usage, performance, and conversion events, such as Source upload, generation requests, export actions, and billing actions. These use bounded categories, counts, and values, not product content. This choice does not enable error reporting. A pseudonymous internal account identifier can connect signed-in activity. We do not create analytics profiles using your email address or name. The SDK uses in-memory analytics persistence rather than persistent analytics cookies.

If you allow Error reporting, browser error reports help us diagnose failures. This choice does not enable pageviews, usage or performance events, or attribution. A pseudonymous internal account identifier can connect signed-in errors for diagnosis. Reports contain a standard error category and, when available, compiled application code locations and line numbers. Raw error messages, source-code context, request or response bodies, prompts, product facts, uploaded or generated images, authentication credentials, and signed file URLs are excluded. Session Replay, automatic click tracking, and console-log forwarding are disabled. The client disables IP-based enrichment; sending a network request still exposes connection information to the receiving service.

Only when Usage analytics is allowed, Lystiva can also send the public landing path, selected UTM values, and the origin of the referrer to its attribution endpoint. The PostHog client filters automatically attached URL, referrer, and person properties before capture. The integration defaults to PostHog's EU ingestion host; the actual project region and provider retention depend on deployment configuration.

When you later sign in and open the workspace, an allowed public landing path can be associated with a pseudonymous workspace-opened milestone. This is not a signup-completed event and does not include the landing URL's query or hash, email address, product facts, or signed storage values.

Use Cookie preferences on this page to reopen the preference dialog, change either optional category, and Save preferences. Closing the dialog without saving leaves your choice unchanged. A previous refusal remains respected until it expires or you change it. Older bundled approvals require a fresh granular choice and never silently enable either category. Changes in another tab and expiry stop newly disallowed collection. Withdrawal does not recall requests already sent or automatically erase events already received by PostHog.

7. Support and voluntary sharing

Support reporting and analytics have separate purposes. Permission for optional analytics is not permission to share reference images, generation instructions, or results for support review. The generation-report backend requires a separate, versioned sharing approval for each report; contact details supplied for a reply must not become email-based analytics profiles.

When the report flow is enabled, the server resolves the exact failed or poor-result generation context, sends consented prompt/reference/result bytes through the configured Resend email channel to PostHog Support, and records only provider acceptance locally. Provider acceptance is not proof that PostHog created, delivered, reviewed, or responded to a ticket. Planning failures disclose when an exact provider prompt was never persisted; they do not relabel a planning brief as a prompt. Selecting a PostHog product during setup is not consent to share your workspace content.

Report context is bounded, private, and removed from the local report record after a terminal delivery outcome or lifecycle deletion. Large image attachments use a deterministic metadata-stripped support copy when eligible; generated result copies preserve the stored final watermark policy. No analytics session/replay, signed URL, raw storage key, raw provider response, or unconsented workspace content is included.

8. Marketing and transactional email

Verification and password-reset emails are transactional messages needed for account access. They are sent through published Resend templates and are separate from marketing subscriptions.

The signup form has an optional marketing checkbox. If you select it, Lystiva adds the signup email address to Resend Contacts, which is shown as Audience in Resend, so Lystiva can send product updates and practical seller tips through Broadcasts. If you do not select it, the application does not add the address through that signup path.

Resend maintains the marketing unsubscribe state. Every marketing Broadcast must include Resend's unsubscribe link or footer. Unsubscribing from marketing does not stop necessary transactional authentication emails.

9. How Lystiva uses data

Lystiva uses the data described above to authenticate accounts, scope workspaces, store and retrieve requested content, analyze accepted Source inputs, prepare and generate requested outputs, create listing copy and export drafts, process billing and credits, prevent abuse, troubleshoot failures, reconcile uncertain provider outcomes, and maintain security and audit records.

Seller content is not made public by default. Export preparation creates a private workspace artifact; downloading it does not publish it. You decide whether to upload the files or copy to a marketplace or another destination, which then applies its own privacy and platform rules.

10. Security and data boundaries

Lystiva enforces workspace scope and parent ownership on the server, keeps provider keys, storage keys, and signed URL authority server-side, stores new binary content through private R2, and bounds uploads, provider responses, and exports.

No internet service can promise that every transmission or system will always be secure. You are responsible for using a unique password, protecting your browser session, and not uploading content that you cannot lawfully or safely submit for processing.

11. Retention, export, and deletion

Lystiva retains account, workspace, content, billing, security, and external-operation records for as long as they are needed to operate the service, resolve provider outcomes, protect users, meet financial or audit obligations, or complete the lifecycle rules that apply to the record. The application does not currently promise one universal retention period for every data category.

The 30-day cookie preference period is not a promise that PostHog events are deleted after 30 days. Hosted event retention is controlled by the PostHog project settings and provider terms, not enforced by this application. A verified hosted retention period must be recorded before this operational draft becomes a final policy.

Workspace settings provide a server-tracked export path when a reviewed and verified durable artifact path is available. Workspace deletion has a preview, policy blockers, fences, and checkpoints; it is currently not an instant erase and can be blocked when billing, provider, audit, storage, or external-effect policy requires retention or manual review.

Archived or removed content can remain in immutable audit, billing, reconciliation, or lifecycle records when removing it would make a financial or external-operation record unreliable. Consent-bound generation-report context is redacted from its report row after terminal delivery and is deleted with its workspace/Source/Job lifecycle. Eligible private bytes are removed only after the service proves that no authorized reference still requires them.

12. Your choices and privacy requests

You can change optional analytics and browser error-reporting permission independently through Cookie preferences on this page, choose whether to join marketing email during signup, unsubscribe from Resend Broadcasts, review or correct seller-owned Source facts in the product, and use the available workspace export and lifecycle controls.

The current repository does not publish a dedicated privacy-request form, legal mailbox, response-time commitment, or automated re-consent history. Those delivery and policy details must be added and tested before this page can serve as the final public privacy notice for a production legal release.

13. Changes to this page

We will update this page when the product's data flows or providers materially change. The current page is a product-accurate operational draft; it has not yet been assigned a legal policy version, effective date, or supersession record.