Privacy

Privacy notice

Last updated 26 August 2026.

Holla provides an AI assistant that brokerages and individual brokers use to reply to customers on WhatsApp and adjacent channels. To make that work, we process personal data on their behalf. This notice explains what data we handle, why, where it lives, and how to get in touch about it.

For our customers (brokerages and individual brokers, who we call Tenants), the legal relationship is a controller to processor one: the Tenant is the data controller of their end customers’ data; Holla is the data processor acting on the Tenant’s documented instructions. For end customers (the property buyers and renters on the other end of a conversation), we are a processor acting under the Tenant’s controllership; direct contact about data should be made to the Tenant first.

Who we are

Holla is an AI assistant for real-estate brokers. During the current period it is operated by Hydrologic Electronics Trading L.L.C, a company licensed in Dubai, United Arab Emirates, which holds the platform’s messaging accounts and customer contracts. A successor entity is being established in DTEC, Dubai Silicon Oasis, and will assume operation of the Service once its licence is issued; your agreements and consent records transfer to it automatically under the succession terms in our Terms of Service and DPA, and we will update this notice when it does. Our Data Protection Officer is Joe Edwards, reachable at privacy@holla.ae.

Data we process

Holla processes the following categories of personal data, only to the extent needed to provide the service:

  • Tenant-side users. Name, email address, Supabase user ID, mobile number, RERA Broker Registration Number (BRN) or Office Registration Number (ORN), role, languages, business hours, brokerage profile, calendar OAuth tokens (when connected).
  • End customers. WhatsApp identifier (phone number), display name, conversation history, voice notes, images and documents sent in conversation, and qualification data the assistant captures during conversation (budget, timeline, financing intent, language preference, neighbourhoods of interest).
  • Listings. Property records sourced from the Tenant’s feeds, CRM, manual entry, or public-portal import. Listings can carry photos and descriptions originating with the Tenant or their data providers, and owner or landlord contact details the Tenant loads.
  • Portal import at onboarding. With the Tenant’s instruction, we read the Tenant’s own public pages on the property portals to import their listings and team roster instead of requiring manual entry. This can include broker names, BRNs, phone numbers and photos as published on those pages. The Tenant confirms it has the right to import this data.
  • Operational metadata. Audit logs of who took what action and when, IP address at signup for PDPL consent records, message-delivery receipts from Meta, model usage for cost telemetry.
  • Billing data. For paying Tenants: plan, billing contact, invoicing history, and payment status. Card details go directly to our payment processor and never touch Holla’s systems; see Payments below.
  • Calendar data (when connected). Free/busy windows on the broker’s primary calendar and events Holla creates on behalf of the broker for property viewings and discovery calls. Holla does not read or transmit event titles, attendees, or descriptions from calendar entries Holla did not create.

What we use it for

Strictly to operate the service. Specifically:

  • Reply to end customers on the Tenant’s behalf through the messaging channels the Tenant connects.
  • Look up the right listing for a conversation, retrieve tenant-authored knowledge, and quote facts with the freshness hedges the system requires.
  • Detect handoff moments (hot lead, frustration, identity probe, out-of-knowledge, stuck loop) so the broker is paged at the right time.
  • Propose and book property-viewing slots against the broker’s calendar when connected.
  • Maintain an audit log so the Tenant can answer regulatory questions about what was said in their name.
  • Bill Tenants for usage, monitor service costs, and detect abuse.

We do not sell personal data. We do not use end-customer conversation content to train general-purpose machine-learning models. Anonymised aggregates and explicit human-curated eval fixtures may be used to evaluate and improve Holla itself; tenant- and end-customer-identifying data is stripped before any such use.

Where data is stored

Holla’s primary database, authentication, file storage, and realtime layer are operated on Supabase EU-West-1 (Ireland), per ADR-0009. Our application servers and job queues run on Railway EU West (Amsterdam). Media files your customers send — voice notes, images, documents — are stored in Cloudflare R2.

Data is therefore stored and processed outside the United Arab Emirates. The cross-border transfer is addressed in the Tenant DPA, including the contractual safeguards it contains; the precise statutory route under the UAE PDPL’s transfer provisions is part of the counsel review our DPA page describes, and we state that plainly rather than assert a conclusion that has not been tested.

We have committed to revisit hosting region every 6 months and to migrate to UAE-region hosting when a stable Big-Three offering or Supabase UAE region becomes available.

Sub-processors we rely on

Holla shares the minimum data needed to deliver the service with the vendors below. This list is kept against what our systems actually connect to, verified against the production codebase, and maintained in a public register. We notify Tenants before engaging a new sub-processor, in line with the DPA.

  • Supabase (Ireland / EU-West-1) — Postgres, auth, storage, realtime, pgvector embeddings.
  • Railway (Netherlands, EU West) — application servers and the message queues; every message in and out passes through.
  • Cloudflare — R2 object storage for the photos, voice notes and documents your customers send, and hosting for the dashboard and admin applications.
  • Anthropic (United States) — large-language-model inference for the assistant.
  • Meta (WhatsApp Cloud API) — WhatsApp message transport and account connection. Meta also processes WhatsApp data under its own terms as an independent controller.
  • Speechmatics and Deepgram — voice-note transcription. Both are live: which one transcribes a given account’s voice notes is set per account, with the other as fallback.
  • Cohere — text embeddings so listings and knowledge documents can be searched; those can carry broker names and contact details.
  • Firecrawl — reads the Tenant’s public portal pages during onboarding for listing and roster import.
  • Resend — transactional email: team invitations, alerts when a lead could not be delivered over WhatsApp, and summary digests.
  • Google — calendar OAuth tokens and event reads / writes when a broker connects their calendar; address lookup for listings. Google processes calendar data under its own API terms. Waitlist signups from holla.ae are also written to a Google spreadsheet, described below.
  • MapTiler — map tiles in the dashboard (browser IP address and map viewport).
  • PostHog (EU region, Frankfurt) — product analytics for the signup flow. It receives your Holla account identifier, your workspace identifier, and the names of the setup steps you reach. It does not receive customer conversations, listing data, names, email addresses, phone numbers or BRNs, and we have session recording and automatic event capture switched off.
  • Sentry — error monitoring with PII scrubbing enabled.
  • Vercel — hosting for this marketing site and our DNS.

Each sub-processor is contractually bound to use data only for the service we instruct, and the list is reviewed whenever the deployment changes.

Payments — Stripe

Paying Tenants are billed through Stripe. Your card details are entered on Stripe’s systems and never reach Holla; we hold only your plan, billing status, and invoicing history. Stripe processes payment data partly as an independent controller for its own fraud-prevention and regulatory purposes, under the Stripe Privacy Policy. Stripe never receives end-customer conversation data. Billing is in AED by Hydrologic Electronics Trading L.L.C as merchant of record; VAT is stated separately on invoices.

Free trials require no card. Nothing is charged unless you choose a plan at the end of the trial.

Waitlist signups on holla.ae

The waitlist form on our marketing site collects a work email address, a brokerage name, a WhatsApp number, and a team-size band. We use them for one purpose: to get in touch when an onboarding slot opens. Signing up does not subscribe you to a newsletter and does not put you on any marketing list.

These entries are stored in a Google spreadsheet (Google Workspace), written through a Google Apps Script endpoint. That means Google processes waitlist data on our behalf, in Google’s own regions rather than the Supabase EU-West-1 estate described above. The lawful basis is your consent, given by submitting the form.

We keep waitlist entries until Holla is generally available and the waitlist is retired, and no longer than 12 months from signup. Entries for people we have onboarded are deleted from the spreadsheet once their account exists. To have your entry removed before then, or to ask what we hold, write to privacy@holla.ae and we will delete it within 30 days.

Booking a call with us

The “book a call” buttons on this site open a booking window served by Cal.com, a scheduling tool we use for sales conversations. That window and its code load from Cal.com only when you open it, so simply reading this site tells them nothing about you. Booking a slot means giving your details to Cal.com directly; nothing is sent to them from Holla’s own systems, and no Tenant or end-customer data is involved. Cal.com may set its own cookies inside that window, and Cal.com’s own privacy notice governs both those and whatever you enter there. We use the resulting booking only to hold the meeting.

Google Calendar data — specific disclosures

When a broker authorises Holla to access their Google Calendar, we ask for the minimum scopes required:

  • calendar.readonly — to read free/busy windows so the assistant can propose viewing slots that don’t conflict with existing events.
  • calendar.events — to write discovery-call and viewing events onto the broker’s calendar after a booking is confirmed.

Holla’s use of information received from Google APIs adheres to Google API Services User Data Policy, including the Limited Use requirements. Specifically:

  • We do not use Google Calendar data for advertising and never transfer it to third parties for advertising purposes.
  • We do not use Google Calendar data to train general-purpose machine-learning models.
  • We do not read titles, attendees, or descriptions of calendar events that Holla did not create.
  • Brokers can revoke Holla’s access at any time from their Google Account permissions page or from Holla’s Settings. Revocation immediately stops all calendar reads and writes.
  • OAuth refresh tokens are stored encrypted at rest in Supabase.

Retention

  • Conversation messages. Retained for the lifetime of the Tenant’s account, unless the Tenant deletes specific conversations or end customers earlier.
  • Voice-note audio files. Purged automatically 90 days after upload, unless the Tenant has explicitly flagged a conversation for extended retention.
  • Audit logs. Retained for a minimum of 12 months for security and regulatory traceability. Where an end customer’s data is erased, audit entries about them are kept with content redacted, leaving only who did what and when.
  • Waitlist signups. Retained until the waitlist is retired at general availability, and no longer than 12 months from signup. Deleted on request at any time.
  • Calendar OAuth tokens. Retained until the broker disconnects calendar integration or deletes their account.
  • End customers who opt out. An end customer who replies STOP, UNSUBSCRIBE, or إلغاء stops receiving messages immediately, and the behavioural profile the assistant kept about them is cleared. The conversation itself is retained as the Tenant’s business record and as the audit trail of the opt-out.
  • End customers whose data is erased. When a Tenant instructs erasure of an end customer (for example, to honour a deletion request), we purge their messages, media, transcripts, qualification data and derived records from live systems. We keep only a minimal suppression record — a keyed, non-reversible reference to the contact, the dates of opt-out or erasure, and redacted audit entries — so the opt-out stays honoured and the erasure can be evidenced. Copies in backups age out on the ordinary backup cycle.
  • Trial accounts that do not convert. A free trial that expires without a subscription is locked to read-only export access for 30 days, then treated as closed; personal data is purged within 90 days after that, as for any closed account.
  • Closed Tenant accounts. Personal data is purged within 90 days of account closure, except where retention is required by applicable UAE law (e.g. tax records).

Your rights under the UAE PDPL

If you are an end customer of a Holla Tenant, your primary point of contact for data-subject requests is the Tenant (typically the brokerage or broker you’ve been speaking with). If you cannot reach them or need an escalation path, you can also write to privacy@holla.ae; we will forward the request to the controlling Tenant and help them respond.

If you are a Tenant-side user (a broker, sales manager, or owner), you can exercise the following rights directly with Holla under the UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021):

  • Access to your personal data.
  • Correction of inaccurate or incomplete data.
  • Erasure where one of the lawful grounds applies.
  • Restriction of processing in defined circumstances.
  • Portability of data you provided to us, in a structured format.
  • Objection to processing on specific grounds.
  • Withdrawal of consent for processing based on consent.
  • Lodging a complaint with the UAE Data Office or, where applicable to the data’s residency, the supervisory authority in your jurisdiction.

Requests should be sent to privacy@holla.ae. We aim to respond within 30 days and will explain any extension in writing.

Security

We follow industry-standard practices: encryption in transit (TLS 1.2+) and at rest, row-level security in Postgres so each Tenant’s data is isolated by default, secrets held as environment variables in our deployment platform, least-privilege access controls for Holla staff, audit-logged administrative actions, and regular dependency review. We will publish a security overview document in line with the DPA.

Cookies and similar technologies

We run no advertising trackers anywhere, and no analytics of any kind on this marketing site, which sets only the cookies needed to serve the pages. Inside the signed-in product we measure how far people get through setup, using PostHog in its EU region. It is configured without cookies and without browser storage, so nothing about it persists on your device between visits. The only thing our authenticated product stores on your device is a session token in localStorage issued by Supabase auth, so that you stay signed in.

Changes to this notice

We will post material changes here with a new “last updated” date and notify Tenant owners by email when the change affects how their data or their end customers’ data is handled. Continued use of Holla after a change indicates acceptance of the updated notice; if a Tenant disagrees with a material change, the route is to terminate the subscription and request deletion under the rights above.

Contact

Questions about this notice or about how your data is handled: privacy@holla.ae. Time-sensitive security disclosures: security@holla.ae.