Skip to privacy notice
Vintraa

Approved beta policy · Version 2026-09-01.1

Vintraa beta privacy notice

Version: 2026-09-01.1

Effective date: 1 September 2026

Controller for Vintraa account and platform data: Zyntria Labs

Privacy and security contact: [email protected]

Company approver: Richie Akparuorji, dev, acting with authority for Zyntria Labs

Approval record: owner approval supplied in the Vintraa release-readiness record on 1 September 2026

1. Scope and roles

This notice describes how Zyntria Labs handles personal data when people visit or use Vintraa, create accounts and workspaces, publish or install agents, use developer tools, contact support or receive service messages.

Zyntria Labs acts as controller for account, security, billing, marketplace, support and platform-operation data. For business data submitted to a workspace at a customer's direction, the customer normally determines the purpose of the processing and Zyntria Labs processes that data to provide the Service. An independent agent publisher may be a separate controller or processor under its own privacy notice. Users should review each agent's declared data practices before installation.

2. Data collected

Depending on use, the Service processes:

  • account data such as name, email, verification state and authentication metadata;
  • workspace membership, business profile, configuration and support contacts;
  • publisher profiles, applications, manifests, release evidence, assets, certification, webhook and developer-credential metadata;
  • installed-agent configuration, permissions, approval records, conversations, knowledge sources, rosters and other content submitted to a workspace;
  • transaction and subscription references received from payment providers;
  • support, governance, security and incident communications;
  • operational data such as request identifiers, timestamps, IP-derived security signals, device/browser information, errors, latency, job state and audit events; and
  • privacy-filtered marketplace analytics when the separately gated analytics cohort is enabled.

The public frontend stores a theme choice and non-secret preferences in local browser storage. A short-lived, non-secret idempotency intent may be kept in session storage to make webhook retries safe. Publisher credentials are held in memory and a reload signs the user out; they are not intentionally persisted in browser storage.

3. Purposes and legal bases

Data is used to provide accounts and contracted features; authenticate and authorise requests; operate workspaces, publishing, installation and agent experiences; process payments; deliver service email; prevent fraud and abuse; scan uploads; investigate incidents; maintain audit and recovery evidence; support users; comply with law; and improve reliability and accessibility.

The applicable basis depends on context and may be performance of a contract, steps requested before a contract, compliance with legal obligations, legitimate interests in operating and securing the Service, or consent where law requires it. Consent can be withdrawn for future optional processing without affecting earlier lawful processing.

4. Marketplace analytics

Marketplace analytics is disabled unless separate legal and privacy gates are enabled. When enabled, the platform uses a closed event dictionary, derives publisher/application/release authority on the server and replaces installation identity with a scoped HMAC pseudonym. Public cells suppress cohorts below 10; raw installation identifiers, raw pseudonyms and overlap aliases are not included in publisher exports. The optional SDK telemetry cohort has a separate gate.

Default analytics retention is 30 days for raw events, 395 days for aggregates and one hour for generated exports. Runtime configuration may shorten these periods. Analytics collection is prospective and disabled periods are not silently backfilled.

5. Sharing and service providers

Data is shared only as needed with authorised workspace members, relevant agent publishers or customers, and providers supporting the Service. Current provider categories include:

  • Railway for application hosting, PostgreSQL, logs and managed recovery;
  • Cloudflare for DNS, network delivery, Workers and R2 object storage;
  • Stripe for applicable payments, subscriptions and payout workflows; and
  • Resend for authentication and service email.

Providers process data under their own security and contractual controls. Data may be processed outside the user's country. Zyntria Labs uses the provider's contractual and legal transfer mechanisms where applicable. Data may also be disclosed when required by law, to protect people or the Service, or in a lawful corporate transaction with appropriate safeguards.

Zyntria Labs does not sell personal data and does not use workspace content to train a general-purpose model unless a separate, explicit agreement and notice authorise it.

6. Retention and deletion

Workspace retention policy defaults are 365 days for ordinary data, conversations and knowledge sources; 730 days for roster data; 2,555 days for audit records; 30 days for generated governance exports; and a 30-day deletion grace period. Workspace owners may change supported policy values. Audit logs and governance-request evidence are retained by policy and are not deleted by ordinary workspace deletion requests.

Publisher webhook payloads default to 30 days. Quarantined publisher assets are removed after processing or rejection, while approved checksum-addressed variants and lifecycle evidence remain until retirement and the applicable cleanup policy. Account deletion anonymises the account and invalidates access; records may remain where needed for security, audit, disputes, financial duties or law. Backup copies may remain until the relevant protected backup expires or is safely overwritten.

7. Security

Controls include scoped authentication and authorisation, tenant checks, encryption in transit, managed encrypted storage, secret separation, malware scanning, checksum-pinned uploads, audit trails, rate limits, bounded jobs, backup recovery and least-privilege provider access. Security is continuously improved, but no system can guarantee absolute security. Suspected incidents should be sent to [email protected].

8. Individual rights

Subject to applicable law, a person may request access, correction, deletion, restriction, portability or objection, and may complain to a competent data protection authority. Workspace owners can use the Service's retention, export and deletion controls for supported workspace categories. Other requests may be sent to [email protected]. Identity and authority will be verified before disclosure or deletion.

9. Children and restricted use

Vintraa is a business beta service and is not directed to children. Accounts must be held by people aged 18 or older. Users must not submit data subject to sector-specific restrictions unless the relevant agreement, controls and agent release expressly support that use.

10. Changes

Material changes will be issued as a new version with a new effective date and will be notified through the Service or the account email when appropriate. Earlier versions remain part of the release record.

App connection information

When you choose to connect an external app through Vintraa Connect, its server receives an app-specific user identifier, workspace and installation identifiers, and current roles and allowed actions. This profile shares no name, email, password or Vintraa account token. Vintraa records when the app acknowledges a connection.

You can disconnect active app sessions. Access ends on the app’s next check. Disconnection does not cancel a paid plan or delete data already held by the developer; use the app’s privacy and billing controls for those requests. Availability is enabled separately in staging and production.