Account and business workspace privacy
Updated 4 October 2026.
ZipVAI LLP operates ZipVAI. For questions or requests to access, correct, export, or delete account information, contact zipvai.net@gmail.com. Requests may require identity and company-authority verification.
Marketing website and application
Hostinger hosts the public marketing pages at zipvai.com and may process website requests, IP addresses, security events, and server logs. These marketing pages contain no sign-in or registration form. Their Sign in and Create account links take you to the application at app.zipvai.com.
The application is the authoritative system for account identity, password hashes, Google identity links when used, secure sessions, companies, invitations, accepted memberships, roles, and suite entitlements. Email sign-up stores a password hash rather than the password. Google sign-in stores the identifiers needed to recognize the account; ZipVAI does not receive a Google password or request Gmail or Drive access.
Company business records
The Finance Suite stores each company’s CodeACS accounting, CRM, and CFA records in that company’s dedicated PostgreSQL database. Accounting data can include fiscal settings, ledgers, journals, reviews, postings, reports, actor references, and audit records. CRM data can include contacts, communication details entered by users, enquiries, opportunities, quotes, follow-ups, reasons, and history. CFA is an internal CodeACS module that stores calculations, assumptions, forecasts, input checksums, and audit lineage; CFA has no direct ledger-posting or money-movement path.
The Growth Suite contains two separate applications. GOM stores reviewed organic social and reputation work in its own PostgreSQL database. SAI stores reviewed SEO, AEO, website, and search work in a different PostgreSQL database. GOM and SAI use distinct service identities, runtime roles, migrations, health checks, backups, and restore procedures. Neither application publishes to providers, performs outreach, buys media, or deploys a website.
Security, sessions, and boundaries
Application requests use secure session cookies. Sessions expire after inactivity and at an absolute limit. Rate-limit records, one-use request identifiers, email-delivery attempts, module-session records, and audit events are used to prevent abuse and enforce company boundaries. Module services receive scoped, short-lived tickets rather than account passwords. Per-company Finance database roles, separate GOM and SAI roles, restricted provisioning identities, and root-controlled backups separate runtime access from administration.
Opening a module never authorizes an external action. Accounting submission, independent approval, and posting remain distinct. Growth approvals remain internal work records. Users should enter only information they are authorized to process.
Retention and backups
Account, membership, entitlement, business, and audit records remain while needed to provide the service, meet security and accounting obligations, resolve disputes, and follow the company’s configured retention decisions. Verification and recovery tokens expire; operational counters are periodically removed. Encrypted backups can retain older copies for a limited recovery period. A deletion or correction request is applied to active systems and handled in backup copies through the applicable retention and recovery process rather than by altering immutable historical backups in place.
No model provider is connected by default. If an AI feature is introduced, its data use, provider, controls, and applicable choices must be disclosed before activation.