Veya · Unada Labs

Privacy Policy

Last updated 16 August 2026. This policy describes the personal data Veya actually processes — not a generic template. It is written for the Digital Personal Data Protection Act, 2023 (DPDP) and the Information Technology Act, 2000.

Veya is operated by Unada Labs. For privacy requests write to privacy@unadalabs.com or hello@unadalabs.com.

1. Who this covers

Three groups of people use Veya, and we treat them separately:

  • Buyers — anyone who opens a project micro-site at /s/… and verifies a mobile number.
  • Workspace users — staff at a developer group (owners, sales, marketing) who sign in to the CRM.
  • Platform staffUnada Labs operators who administer tenants, billing, and support sessions.

2. What we collect — buyers

When you verify on a project page we collect:

  • Mobile number, and a one-time SMS code to prove you control it.
  • A salted hash of that number (HMAC-SHA256). The hash is what we use to count you once per project per billing period so a developer is not charged twice for the same person. Rotating the salt would reset that count.
  • Optional name, visit preferences, and message when you submit an enquiry, callback, brochure, or site-visit request.
  • How you use the micro-site: sections opened, units and floor plans viewed, dwell time, return visits. This is scored so the sales team knows who to call and what to open with — it is not sold as an advertising graph.
  • A device signal stored in this browser (a random identifier, not a cross-site advertising fingerprint). It is used only to detect when the same device opens a forwarded link under a different number.
  • A coarse hashed IP used for OTP abuse throttling. It is not reversed or shown in the CRM.

You can close the page without verifying. Unverified visitors are not stored as leads.

3. What we collect — workspace and platform users

  • Name, work email, password (bcrypt hashed, never stored in plain text), optional phone and job title.
  • Organisation profile: legal name, GSTIN, billing address, support contacts, logo, brand colours.
  • Project content you upload (renders, brochures, floor plans) and the micro-site copy you publish.
  • Billing records: invoices, payments, top-up credits, usage counters for verified buyer profiles.
  • An audit log of consequential actions (role changes, publishes, comps, support session entry).
  • A session cookie (HTTP-only JWT). We re-read your role from the database on every request so a suspension takes effect immediately. Optional TOTP for platform MFA.

4. Why we process it

Purposes are limited to:

  • Identifying genuine buyer interest and unlocking project details after OTP.
  • Letting the developer’s sales team contact you about that project when you ask.
  • Scoring engagement so the team knows who to call, not to profile you for ads.
  • Metering unique verified buyers per project so the developer is billed fairly.
  • Running the workspace: team, billing, analytics, and support.
  • Security: OTP cooldowns, hashed IPs, audit trails, support-session least privilege.

We do not sell mobile numbers. We do not run cross-site advertising pixels on buyer pages.

5. Who sees buyer details

The developer organisation that owns the project, and the sales teammate attributed to the share link you opened. Attribution is bound once — a later forwarded link does not steal the lead. Unada Labs processes the data to host Veya. Platform staff entering a customer workspace do so under a separate, time-limited support session that is read-only by default.

If the developer has connected a CRM (Salesforce or Zoho when live; a dummy adapter in demo mode), lead fields they map may be copied there. That connection is under their control.

6. Subprocessors — only when configured

In local and demo deployments every vendor key is empty and providers run as console/dummy adapters — data stays on the application server. In production the operator may enable:

  • MSG91 — transactional SMS for OTP.
  • Razorpay — card/UPI collection for invoices and top-ups.
  • Resend — transactional email (invites, payment notices).
  • Google Gemini — brochure text extraction into the project builder, when a workspace uploads a PDF.
  • Amazon S3 or Vercel Blob — uploaded media.
  • The hosting and PostgreSQL provider that runs the application.

7. Retention

Buyer leads and analytics remain for as long as the developer workspace is active, because they are the working records of a sales conversation. When a workspace is offloaded or deleted by the operator, associated micro-sites go offline and tenant data is tombstoned per the operator runbook. Session cookies expire; support-session cookies last eight hours. OTP challenges expire in minutes. Credit-ledger and invoice rows are kept for tax and billing history.

8. Your rights (DPDP)

You may request access, correction, or erasure of personal data we hold, or withdraw consent for marketing contact about a project. Buyers should first contact the developer named on the micro-site (they are the sales controller for that conversation). You may also write to Unada Labs at privacy@unadalabs.com. We will need enough detail to locate the record (typically the mobile number used at the gate) and may refuse requests that we cannot authenticate, or that would break a legal retention duty (for example a paid invoice).

A full self-serve data-subject console is not shipped in this version of Veya; requests are handled by email. Lead CSV export is available to workspace roles that hold lead:export, and those exports are audited.

9. Children

Veya is built for property sales to adults. We do not knowingly collect personal data from children. If you believe we have, write to privacy@unadalabs.com and we will delete the record.

10. Grievance officer

Until a named Grievance Officer is published, privacy complaints can be sent to privacy@unadalabs.com with the subject line “Grievance — Veya”. We aim to acknowledge within 72 hours.

11. Changes

We will update the date at the top of this page when the policy changes. Material changes that affect buyers (for example a new fingerprint use) will also be reflected on the OTP gate, which links here.