PRIVACY POLICY

Doorkee www.doorkee.co

Effective Date: 19 March 2026 Last Updated: 2 May 2026

1. Introduction

1.1. This Privacy Policy ("Policy") explains how DoorKee FZ-LLC ("Doorkee," "we," "us," "our," or the "Company"), a Free Zone Limited Liability Company registered in the Ras Al Khaimah Economic Zone (RAKEZ), United Arab Emirates, with registered office at FOAM0424, Compass Building, Al Shohada Road, Al Hamra Industrial Zone-FZ, Ras Al Khaimah, collects, uses, stores, discloses, and protects your personal data when you access or use our website at www.doorkee.co, our mobile applications, and any related services (collectively, the "Platform").

1.2. Doorkee is the UAE's first outcome-driven rental platform, connecting property owners and tenants to facilitate residential rental transactions. By using the Platform, you agree to the collection and use of your information in accordance with this Policy.

1.3. This Policy has been prepared in compliance with:

• UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (the "UAE Data Protection Law");

• Applicable regulations issued by the UAE Data Office;

• Where applicable, the principles of the General Data Protection Regulation (EU) 2016/679 ("GDPR"), for users who may be residents of the European Economic Area.

  1.4. If you do not agree with this Policy, you should not use the Platform.

2. Information We Collect

We collect different categories of personal data depending on how you interact with the Platform.

2.1. Account Registration Data

When you create an account, we collect:

• First name (required) and last name (optional);
• Email address (required);
• Password (never stored in plaintext; processed through Supabase Auth with bcrypt hashing);
• Phone number (collected during registration or identity verification);
• Login provider information, if you register via Google OAuth or Apple OAuth (we receive your name and email from the OAuth provider; we never receive or store your Google or Apple password).

2.2. Identity Verification (KYC) Data

When you perform certain actions on the Platform (such as shortlisting a property, scheduling a visit, placing an offer, or listing a property), you are required to complete identity verification. We collect:

• User type (owner or tenant);
• Nationality;
• Verification method selected (national ID, passport, or driver's licence);
• Identity document images (front and back scans of your selected document, stored securely in Supabase Storage);
• Document details extracted during verification, including document ID number, full name as it appears on the document, and date of birth;
• Phone verification status (verified via one-time password sent to your email);
• Verification status (not started, in progress, pending, verified, or rejected).

2.3. Property Data

If you are a property owner listing a property, we collect:

• Property details: name, address, square footage, bedroom count, bathroom count, property type, furniture type, category, and description;
• Financial information: rental amount (annual rent in AED), preferred cheque count;
• Location data: latitude and longitude coordinates (if provided);
• Property documents: Ejari registration document, title deed, tenancy contract, and RERA permit number (all optional);
• Property images (uploaded to Supabase Storage);
• Amenity selections;
• Visit schedule: available dates and time slots for property viewings;
• Property management data: tenant type preferences, pet policy, tour approval type, community information, possession start date, and lease end date.

2.4. Offer and Transaction Data

When you place or receive rental offers, we collect:

• Offer details: offer amount, cheque count, preferred move-in date, offer change count, expiry time, and optional personal note (free-text message you may attach to your offer);
• Counter-offer details: counter-offer amount and counter cheque count;
• Offer status history (decision pending, accepted, rejected, renegotiated, expired, not selected, withdrawn).

2.5. Payment Data

When you make payments on the Platform (e.g., reserve payments for fourth or subsequent offer changes):

• Payment processing: All payment card details are processed directly by Stripe, our PCI DSS-compliant payment processor. We never receive, access, or store your full card number, CVV, or PIN.
• Transaction records we store: transaction type, amount, currency (AED), Stripe payment intent ID, Stripe charge ID, Stripe payment method ID (a tokenised reference), transaction status, failure reason (if applicable), refund amounts, and refund dates.

2.6. Visit and Scheduling Data

When you book property viewings, we collect:

• Visit details: property visited, date, time slot, visit status (scheduled, completed, cancelled);
• Visit notes (if provided);
• Reminder status: when the last visit reminder was sent.

2.7. AI Concierge (Dara) Data

Our AI-powered rental concierge, Dara, collects and processes the following data to provide personalised assistance:

• Conversation history: all messages exchanged between you and Dara, including your questions, requests, and Dara's responses;
• User preferences learned from interactions: bedroom count preferences, budget range, preferred areas/communities, furniture preferences, and desired amenities;
• Journey stage: your current stage in the rental process (browsing, comparing, viewing scheduled, offered, accepted, rented, renewal window);
• Behavioural signals: shortlisted properties, rejected properties, objections raised (e.g., "too expensive," "too far"), positive signals (e.g., "looks good," "interested"), sentiment indicators;
• Relationship data: conversation count, relationship tier (stranger, acquaintance, regular, VIP), first interaction date, and deal completion date;
• Discussed topics: a record of up to 20 recent topics discussed with Dara;
• Tool usage: records of actions Dara performs on your behalf (property searches, pricing lookups, offer placements, viewing bookings), including the parameters used and results returned;
• Alert subscriptions: alert type, criteria, and preferred notification channel;
• Feedback: any upvotes or downvotes you provide on Dara's responses, along with context about the message being evaluated;
• Handoff request data: when you ask to speak to a Doorkee specialist (or accept a system-card offer to do so), we persist the handoff request, a short PII-redacted reason summary, the conversation ID, the routing lane, a 5-minute idempotency dedupe key, and (if applicable) the SLA-breach timestamp to the AI Concierge audit log. We also persist the offer-card surface state — when a card was shown to you (handoff.offered), when you dismissed it (handoff.dismissed), when the server's rate limiter prevented a re-offer (handoff.ratelimited), and when Dara asked the ambiguous-target clarifier (handoff.clarifier_asked) — so we can honour the rate-limit caps that prevent us from interrupting you with the same card repeatedly and so the clarifier is asked at most once per conversation;
• Frustration-target classification: when your message expresses frustration in a way that requires routing triage, Dara classifies whether the frustration target is Doorkee/Dara or an external entity (the rental market, a landlord, visa rules, etc.). We record only the classification outcome and which §15.10 rule fired, not a profile of you. The classification is used to decide whether to surface the offer card and is retained alongside the audit-log row above.

2.8. Search and Usage Data

We collect information about how you use the Platform:

• Search logs: search filter parameters and result counts (linked to your user ID if logged in, anonymous if not);
• Shortlist activity: properties you save to your shortlist;
• Analytics events: event type, associated metadata, and timestamps for actions such as searches, property views, offers, and conversation starts.

2.9. Lease and Property Management Data

If you have an active lease managed through the Platform, we collect:

• Lease details: lease type (new or renewal), start date, end date, monthly rent, security deposit, lease status, and lease document URL;
• Maintenance requests: issue type, description, notes, attachments, cost breakdowns (total, tenant, owner), resolution details, and dates;
• Invoices: invoice type (rent, service, maintenance), service description, amount, currency, billing date, due date, payment status, and receipt URL.

2.10. Technical Data

We automatically collect certain technical information when you use the Platform:

• IP addresses: collected for rate limiting purposes (to prevent abuse such as brute-force login attempts) and security monitoring. IP addresses are also logged in AI Concierge audit logs for security purposes;
• Device and browser information: collected via standard HTTP headers;
• Authentication cookies: Supabase session cookies required for login functionality (see Section 7 for details).

2.11. Company Data

If you represent a company on the Platform, we may collect:

• Company details: company name, email, phone number, and logo.

3. How We Use Your Information

We use the personal data we collect for the following purposes:

3.1. Providing the Platform Service

• Creating and managing your account;
• Facilitating property listings, searches, and comparisons;
• Processing rental offers and counter-offers between tenants and owners;
• Scheduling and managing property visits;
• Managing leases, maintenance requests, and invoices;
• Sending visit reminders and offer expiry notifications.

3.2. Payment Processing

• Processing reserve payments through Stripe for fourth and subsequent offer changes;
• Managing refunds for unsuccessful offers;
• Reconciling payment records;
• Maintaining transaction history for your records and our legal obligations.

3.3. AI Concierge Personalisation

• Powering Dara, our AI concierge, to provide personalised rental recommendations;
• Learning your preferences from conversations and tool interactions to improve suggestions over time;
• Tracking your journey stage to provide contextually relevant assistance;
• Generating proactive insights such as price drop alerts and new listing matches;
• Providing market data, pricing intelligence, and negotiation guidance based on Dubai Land Department (DLD) data;
• Routing handoff requests to a Doorkee specialist when you ask to speak to one or accept a system-card offer to do so, including classifying whether a frustration signal points at Doorkee/Dara or at an external target so we can decide whether to surface the offer card.

3.4. Identity Verification and Fraud Prevention

• Verifying user identities before allowing sensitive actions (offers, listings, visits);
• Preventing duplicate accounts and fraudulent activity;
• Rate limiting login attempts, registration, and password reset requests to prevent brute-force attacks;
• Auditing AI Concierge tool executions for security review.

3.5. Communications

• Sending transactional email notifications via Resend for events including: new offers received, offer status changes, visit confirmations, visit reminders, verification status updates, and property approval decisions;
• Sending alert notifications based on your subscriptions (price drops, new listings matching your criteria, renewal reminders, market shifts).

3.6. Analytics and Service Improvement

• Analysing search patterns and user behaviour to improve Platform features;
• Monitoring AI Concierge quality through feedback aggregation and response scoring;
• Running A/B experiments on AI Concierge prompts to improve response quality;
• Generating market intelligence from aggregated, anonymised usage patterns;
• Monitoring errors and Platform health through Sentry.

3.7. Legal Compliance

• Complying with UAE laws and regulations, including anti-money laundering requirements;
• Responding to lawful requests from government authorities and law enforcement;
• Establishing, exercising, or defending legal claims;
• Maintaining records as required by applicable law.

3.8. Legal Basis for Processing

We process your personal data on the following legal bases under the UAE Data Protection Law:

• Contractual necessity: Processing required to provide the Platform services you have requested (Sections 3.1, 3.2, 3.5), including routing your handoff requests to a Doorkee specialist when you ask to speak to a human or accept a system-card offer to do so. The handoff request, a short PII-redacted reason summary, the conversation ID, the routing lane, and the SLA-breach timestamp are persisted to ConciergeAuditLog for the audit retention period (Section 6.8). Legal basis: PDPL Art. 6(1)(b);
• Legitimate interest: Processing for security, fraud prevention, analytics, and service improvement (Sections 3.4, 3.6), including classifying whether a frustration expression points at Doorkee/Dara or at an external target for operational triage (we record only the classification outcome, not a profile; we balance this against your interests by not using the outcome for advertising or third-party sharing and by honouring objection requests via the DPO contact in Section 12). Legal basis: PDPL Art. 6(1)(f);
• Legal obligation: Processing required to comply with applicable laws (Section 3.7);
• Consent: Processing of optional data and AI Concierge personalisation (Section 3.3). You may withdraw consent at any time (see Section 8).

4. Information Sharing and Disclosure

We share your personal data only in the following circumstances:

4.1. Between Platform Users

• Tenants and owners: When you place an offer on a property, the property owner can see your first name and offer details (amount, cheque count, preferred move-in date). Full property addresses are visible on listings. Contact details are shared only after a deal is accepted.
• Visit scheduling: When you book a visit, the property owner is notified of the scheduled date and time.

4.2. Payment Processor — Stripe

We share necessary transaction data with Stripe, Inc. (headquartered in the United States) to process payments. Stripe is PCI DSS Level 1 certified. Stripe's handling of your data is governed by Stripe's Privacy Policy. Data shared includes: transaction amounts, currency, and payment method tokens. We never share your full card details with Stripe through our systems; those are collected directly by Stripe's secure payment elements.

4.3. Email Provider — Resend

We share your email address and notification content with Resend to deliver transactional emails (offer notifications, visit reminders, verification updates). Resend processes this data solely for email delivery on our behalf.

4.4. AI Service Providers

To power Dara, our AI concierge, we transmit conversation data to the following AI model providers:

• Anthropic (Claude models) — headquartered in the United States;
• OpenAI (GPT models) — headquartered in the United States;
• Google (Gemini models) — headquartered in the United States.

The data sent to these providers includes: your conversation messages, relevant context about your preferences and journey stage, and the results of tool calls. These providers process the data to generate AI responses and do not use your data to train their models (per our enterprise agreements). Conversations are routed to different providers based on complexity (simple queries, complex analysis, or image-based requests).

4.5. Cloud Infrastructure — Supabase

All Platform data is stored on Supabase infrastructure, which provides our PostgreSQL database, user authentication, and file storage services. Supabase data is hosted on cloud infrastructure.

4.6. Error Monitoring — Sentry

We use Sentry for error monitoring and application performance tracking. When errors occur, Sentry may receive technical context including: error messages, stack traces, request URLs, and anonymised user identifiers. Sentry does not receive your personal content or conversations.

4.7. Rate Limiting — Upstash Redis

We use Upstash (Redis-based) for rate limiting to prevent abuse of authentication endpoints. Upstash stores only rate limit counters keyed by hashed IP addresses. No personal content, names, or email addresses are sent to Upstash.

4.8. Hosting — Vercel

The Platform is hosted on Vercel. Vercel processes HTTP requests and may have access to IP addresses and request headers as part of standard hosting infrastructure.

4.9. Law Enforcement and Legal Requirements

We may disclose your personal data to law enforcement agencies, regulatory authorities, or other third parties if required to do so by law, court order, or legal process, or if we believe in good faith that such disclosure is necessary to:

• Comply with applicable law or regulation;
• Protect our rights, property, or safety, or that of our users or the public;
• Investigate or prevent suspected fraud or illegal activity.

4.10. Business Transfers

In the event of a merger, acquisition, reorganisation, or sale of all or a portion of our assets, your personal data may be transferred to the acquiring entity. We will provide notice before your personal data becomes subject to a different privacy policy.

4.11. No Sale of Personal Data

We do not sell your personal data to third parties. We do not share your personal data with third parties for their independent marketing purposes.

5. Data Security

We implement the following technical and organisational measures to protect your personal data:

5.1. Encryption

• All data transmitted between your device and our servers is encrypted using HTTPS/TLS;
• Data at rest in our database is encrypted by Supabase's infrastructure.

5.2. Database Security

• Row Level Security (RLS): Our PostgreSQL database enforces row-level security policies, ensuring that users can only access data they are authorised to view. RLS policies are enforced at the database level, independent of application code;
• Parameterised queries: All database queries use Prisma ORM with parameterised inputs to prevent SQL injection attacks.

5.3. Authentication Security

• Password hashing: Passwords are hashed using bcrypt via Supabase Auth. We never store plaintext passwords;
• Account enumeration prevention: Login, registration, and password reset responses are designed to prevent attackers from determining whether an account exists;
• Rate limiting: Authentication endpoints (login, register, forgot password) are rate-limited to 6 attempts per minute per IP address to prevent brute-force attacks;
• Secure session management: Authentication sessions are managed via Supabase with HTTP-only, secure cookies;
• OAuth security: Google and Apple OAuth flows use validated redirect URLs with origin checking to prevent open redirect attacks.

5.4. Access Controls

• Role-Based Access Control (RBAC): Administrative access is controlled through a granular permission system with roles, modules, and permissions;
• Admin portal separation: The admin login portal is separated from the user login portal, with server-side enforcement;
• Deactivated account enforcement: Deactivated accounts cannot log in, even with valid credentials.

5.5. AI Concierge Security

• Prompt injection protection: Dara includes defences against prompt injection attacks;
• Tool execution auditing: All actions Dara performs on behalf of users are logged to an audit trail with user ID, IP address, tool name, parameters, and results;
• Access control: User conversations are private; authenticated users can only access their own conversation history;
• Message role validation: Conversation messages loaded from the database are validated to prevent instruction injection;
• Input sanitisation: User inputs are sanitised before storage to prevent cross-site scripting and injection attacks.

5.6. Infrastructure Security

• Rate limiting: All API endpoints are protected by rate limiting via Upstash Redis, with per-process fallback keys;
• CRON job authentication: Scheduled background tasks (offer expiry, payment reconciliation, conversation cleanup) are protected by timing-safe secret verification;
• Origin validation: Email redirect URLs are validated against an allowlist of trusted origins.

6. Data Retention

We retain your personal data for the following periods:

6.1. Account Data

Your account data (name, email, phone, user type) is retained for as long as your account remains active. You may request deletion of your account at any time (see Section 8).

6.2. Identity Verification Data

Verification documents and identity information are retained for as long as your account remains active and for any additional period required by UAE anti-money laundering or know-your-customer regulations.

6.3. Conversation History

• Anonymous conversations (from users who are not logged in): Automatically deleted after 30 days by our scheduled cleanup process;
• Authenticated user conversations: Retained until you request deletion of your account.

6.4. AI Concierge Memory

User preferences, journey state, behavioural patterns, and relationship data are retained until you:

• Request a preference reset (clears search preferences but preserves relationship data); or
• Request full account deletion (complete data erasure compliant with privacy regulations).

6.5. Soft-Deleted Records

When certain records are "deleted" on the Platform (properties, offers, shortlists, visits, leases, maintenance requests, invoices), they are soft-deleted — marked with a deletion timestamp but retained in the database for audit and legal compliance purposes. Soft-deleted records are hidden from the user interface.

6.6. Payment and Transaction Records

Payment transaction records are retained in accordance with UAE financial record-keeping requirements, which may require retention for a minimum period after the transaction date even after account deletion.

6.7. Search Logs and Analytics

Search logs and analytics events are retained for platform improvement purposes. These may be anonymised after 12 months.

6.8. Audit Logs

Doorkee maintains two categories of audit logs in the ConciergeAuditLog table: AI Concierge tool-execution records (every tool call Dara makes on your behalf) and PDPL consent-decision records (every Accept-all, Essentials-only, Customise-Save, or Revoke action you take in the cookie banner or footer).

These rows are retained for 5 years (1,825 days) and then anonymised in place — your userId, IP address, user-agent string, and any personal data carried inside the audit row's toolArgs payload are set to NULL. The tool name, timestamp, and outcome remain so we can investigate security incidents, fraud patterns, and AML flags after the fact. The right_to_erasure_executed action carries a 7-year retention window before anonymisation, in line with the audit-trail requirements of UAE Federal Decree-Law No. 20 of 2018 (Anti-Money Laundering).

Effect on Right to Erasure (Art. 17): when you exercise your right to have your personal data erased (described in §8.3), Doorkee removes your identifying information from the audit rows but does not delete the rows themselves. After anonymisation the rows are reduced to a form that no longer reasonably identifies a natural person under PDPL Art. 1 (the definition requires that the data identify, or be reasonably capable of identifying, a natural person), so their retention is consistent with both Art. 14 (data minimisation satisfied by anonymisation) and Art. 26 (retention for compliance with a legal obligation — here, AML/CFT and cybercrime investigation).

This is one of a small number of narrowly-scoped Art. 17 retention carve-outs Doorkee asserts, alongside the KYC retention described in §6.2 and the financial-record retention described in §6.6. All other personal-data fields tied to your account — including profile data, KYC documents, property listings, offers, transactions, and lease records — are erased or anonymised on the schedule described elsewhere in §6.

7. Cookies and Tracking Technologies

7.1. Consent Model

Doorkee uses three categories of cookies and trackers:

• Strictly necessary — always on. Required for authentication, payment processing, CSRF protection, session management, and security. You cannot disable these while using authenticated features of the Platform.
• Analytics — opt-in. Product analytics (PostHog Inc.), error monitoring (Sentry), Google Tag Manager, and Microsoft Clarity are used to fix problems, measure usage, and improve Dara. All are gated on your analytics-consent toggle in the cookie banner: disabled by default, enabled only with your explicit consent.
• Marketing — opt-in. Reserved for future ad-campaign measurement. We do not currently run paid ad campaigns. Disabled by default; enabled only with your explicit consent.

The dk_pdpl_v1 cookie that records your choice is itself a strictly necessary cookie and is set with HttpOnly=false so the in-page consent banner can read it directly without an extra round-trip to the server. The cookie carries no identifiers, no tracking value, and no personal data — only the booleans analytics, marketing, a timestamp, and a version. The authoritative copy of the choice (with your user ID and IP) lives in the server-side audit log described in §7.2; the cookie is the read-only mirror.

7.2. How Consent is Recorded

When you respond to the cookie banner, your choice is stored in two places:

• A first-party cookie dk_pdpl_v1 on your device (12-month expiry). This is the client-side gate that enables or disables analytics and marketing scripts.
• A server-side audit record (ConciergeAuditLog entry with action: "pdpl_consent_recorded") including the timestamp, your user ID (if signed in, otherwise null), IP address (for anti-abuse), and the analytics/marketing choice. This is retained per PDPL Art. 6 proof-of-consent requirements.

7.3. Default Posture

Until you respond to the banner — or if you dismiss it without choosing — the analytics category (PostHog Inc., Sentry, Google Tag Manager, Microsoft Clarity) and the marketing category are disabled. Strictly necessary cookies remain active.

7.3a. Cross-Border Transfers from Analytics Providers (PDPL Art. 22)

When you grant analytics consent, the following providers receive limited usage data and may process it outside the UAE. We disclose the controllers and processing locations here so your consent is informed:

• Google Tag Manager — operated by Google Ireland Limited (controller for users in the EEA, the UK, and Switzerland) on behalf of Google LLC (US). Tag Manager itself is a script-loading container; the tags it loads are limited to product analytics (PostHog Inc. and Microsoft Clarity, both listed below) and do not include behavioural advertising tags. Data transferred via Google's infrastructure is processed in the United States and the European Union under Google's cross-border transfer mechanisms (EU Standard Contractual Clauses, the EU-US Data Privacy Framework, and equivalent UK/Swiss safeguards). Reference: https://policies.google.com/privacy.
• Microsoft Clarity — operated by Microsoft Ireland Operations Limited (controller for users in the EEA, the UK, and Switzerland) on behalf of Microsoft Corporation (US). Clarity collects session-replay metadata (clicks, scrolls, page navigation) and aggregated heatmaps, with text content masked by default. Data is processed in the United States and the United Kingdom under Microsoft's Data Protection Addendum, EU Standard Contractual Clauses, and the EU-US Data Privacy Framework. Reference: https://privacy.microsoft.com/privacystatement.

• PostHog Inc. — operated by PostHog Inc. (United States), the analytics processor for both server-side and in-browser product analytics events. Doorkee is the controller; PostHog Inc. is the processor under a Data Processing Addendum. Data minimisation: server-side events transmit a one-way truncated pseudonymous identifier in place of the raw user ID (see §7.3b); the identifier is a 16-character hex digest produced by keyed HMAC-SHA-256 when the server-side TELEMETRY_HASH_SECRET environment variable is set in production, and by an unkeyed SHA-256 fallback (also 16-character truncated) during the transitional grace period before that environment variable is set, with each fallback emission tagged in our internal monitoring (Sentry alert_category: hash_salt_rotation). Both forms are one-way digests; neither is reversible without prior knowledge of the original user ID, and the keyed form additionally requires the server-side secret. In-browser events fire only after analytics consent. Retention: configured to honour the $delete_user Personal Data API on DSAR completion (see §15.6). Cross-border safeguards: EU Standard Contractual Clauses + EU-US Data Privacy Framework. Reference: https://posthog.com/privacy.
• Meta WhatsApp (Cloud API) — operated by Meta Platforms Ireland Limited (controller for users in the EEA, the UK, and Switzerland) on behalf of Meta Platforms, Inc. (US). Doorkee is the controller for the conversation content; Meta is the processor for delivery and Cloud-API metadata. Data minimisation: Doorkee transmits only the recipient phone number, message body, and template ID required to deliver the message; no PostHog identifier or other analytics data is shared. Retention: subject to Meta-side platform retention floors (described in §15.6 row "Meta WhatsApp") that Doorkee cannot override. Cross-border safeguards: EU Standard Contractual Clauses + EU-US Data Privacy Framework. Reference: https://www.whatsapp.com/legal/business-data-transfer-addendum.
• Resend Inc. — operated by Resend Inc. (United States), the transactional and lifecycle email delivery processor. Doorkee is the controller; Resend Inc. is the processor under a Data Processing Addendum. Data minimisation: only recipient email address, subject, body, and delivery-status metadata are transmitted. Retention: 30 days for delivery logs (see §15.6 row "Resend"). Cross-border safeguards: EU Standard Contractual Clauses + EU-US Data Privacy Framework. Reference: https://resend.com/legal/privacy-policy.

These transfers are made under the safeguards described in §10 (International Data Transfers) and only after you have granted analytics consent (where consent is the lawful basis — server-side events under §7.3b operate under PDPL Art. 4 lawful basis instead). Withdrawing consent (see §7.4) stops the consent-gated scripts from loading on subsequent visits.

7.3b. Server-Side Analytics Identifiers (PDPL Art. 4 lawful-basis processing)

Some analytics events fire from server contexts that have no cookie or consent state available — for example, payment-processor webhooks (Stripe), background jobs (Inngest), and admin actions. These events are processed under PDPL Art. 4 lawful-basis grounds (fraud prevention, contract performance, and operational reliability) rather than under the consent regime in §7.3.

For these events, Doorkee transmits a one-way truncated pseudonymous identifier — derived from your user ID — as the analytics distinctId, in place of the raw user ID. The identifier is a 16-character hex digest produced by keyed HMAC-SHA-256 (server-side secret-keyed) when the TELEMETRY_HASH_SECRET environment variable is set in production. During the transitional grace period before that environment variable is set, an unkeyed SHA-256 fallback (also 16-character truncated) is emitted instead, with each fallback emission tagged in our internal monitoring (Sentry alert_category: hash_salt_rotation) so the operations team can confirm the secret is rotated in. Both forms are one-way digests; neither is reversible without prior knowledge of the original user ID, and the keyed form additionally requires the server-side secret. PostHog Inc. cannot recover your identity from either form alone.

In-browser analytics scripts continue to honour the cookie consent toggle described in §7.3 above. PostHog Inc. is the analytics processor for both server-side and in-browser events; cross-border safeguards are addressed in §7.3a.

7.4. Changing Your Choice

You can change your consent at any time:

• Via the "Cookie settings" link in the Platform footer.
• By clearing your browser cookies (which removes dk_pdpl_v1 and re-shows the banner on next visit).
• By contacting the Data Protection Officer at dpo@doorkee.co — we will re-issue a consent prompt on your next login.

Withdrawing analytics or marketing consent stops the corresponding scripts (Google Tag Manager, Microsoft Clarity, PostHog Inc.) from loading on subsequent page loads. Scripts already loaded into the current page continue running until you navigate or refresh; you can force immediate effect by reloading the page.

7.5. No Third-Party Advertising Cookies

We do not currently use behavioral advertising cookies, tracking pixels, or programmatic ad-retargeting technologies. If this changes, the privacy policy will be updated and a new consent prompt will be issued before any new category is activated.

7.6. Data Protection Officer

Questions about cookies, data processing, or your PDPL rights: dpo@doorkee.co.

8. Your Rights

Under the UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data, and where applicable under the GDPR, you have the following rights regarding your personal data:

8.1. Right of Access

You have the right to request confirmation of whether we process your personal data and to obtain a copy of that data. Much of your data is directly accessible through your Platform account (profile, offers, visits, conversations, shortlists).

8.2. Right to Rectification

You have the right to request correction of inaccurate or incomplete personal data. You can update your profile information directly through the Platform. For corrections to verification data, please contact us.

8.3. Right to Erasure (Right to Be Forgotten)

You have the right to request deletion of your personal data, subject to our legal obligations to retain certain records. When you request account deletion:

• Your account and profile data will be deleted;
• Your AI Concierge memory will be permanently erased (full GDPR-compliant data erasure);
• Your conversation history will be deleted;
• Certain transaction records may be retained as required by law (see Section 6.6);
• Soft-deleted records associated with your account will be permanently removed upon request.

8.4. Right to Data Portability

You have the right to request your personal data in a structured, commonly used, and machine-readable format. Contact us to request a data export.

8.5. Right to Restrict Processing

You have the right to request restriction of processing of your personal data in certain circumstances, such as when you contest the accuracy of the data or object to its processing.

8.6. Right to Object

You have the right to object to processing of your personal data based on our legitimate interests. If you object, we will cease processing unless we demonstrate compelling legitimate grounds that override your interests.

8.7. Right to Withdraw Consent

Where we process your data based on consent (such as AI Concierge personalisation), you may withdraw your consent at any time. Withdrawal of consent does not affect the lawfulness of processing carried out before the withdrawal. You can:

• Reset your AI Concierge preferences through a conversation with Dara;
• Request full data erasure by contacting us;
• Discontinue use of the Platform.

8.8. Exercising Your Rights

To exercise any of these rights, contact us at:

• Email: support@doorkee.co
• Subject line: "Data Privacy Request — [Your Right]"

We will respond to your request within 30 days. We may request verification of your identity before processing your request to protect your data from unauthorised access.

8.9. Right to Lodge a Complaint

If you believe your data protection rights have been violated, you have the right to lodge a complaint with the UAE Data Office or, if applicable, a supervisory authority in the European Economic Area.

9. Children's Privacy

9.1. The Platform is not intended for use by individuals under the age of 18. We do not knowingly collect personal data from children under 18.

9.2. If we become aware that we have collected personal data from a child under 18, we will take immediate steps to delete that data from our systems.

9.3. If you are a parent or guardian and believe your child has provided personal data to us, please contact us at support@doorkee.co so we can take appropriate action.

10. International Data Transfers

10.1. Doorkee is based in the United Arab Emirates. However, your personal data may be transferred to and processed in countries outside the UAE, including the United States, in connection with our use of the following service providers:

| Service Provider | Purpose | Location | | ----------------- | -------------------------------------------- | ------------------- | | Stripe | Payment processing | United States | | Anthropic | AI Concierge (Claude models) | United States | | OpenAI | AI Concierge (GPT models) | United States | | Google | AI Concierge (Gemini models) | United States | | Supabase | Database, auth, storage | Cloud (US/EU) | | Resend Inc. | Transactional and lifecycle email delivery | United States | | Sentry | Error monitoring | United States | | PostHog Inc. | Product analytics (server-side + in-browser) | United States | | Twilio | SMS delivery and WhatsApp transport | United States | | Meta WhatsApp | WhatsApp messaging (Cloud API) | United States / EU | | Inngest | Background event queue (cron + DSAR cascade) | United States | | Upstash | Rate limiting (Redis) | Cloud | | Vercel | Application hosting | Global edge network |

10.2. When transferring data outside the UAE, we ensure appropriate safeguards are in place, including:

• Contractual obligations with our service providers requiring them to protect your data to a standard equivalent to UAE law;

• Use of service providers that maintain industry-standard security certifications (e.g., SOC 2, PCI DSS);

• Data minimisation — we transfer only the minimum data necessary for each service provider to perform its function.

  10.3. For users in the European Economic Area, transfers are made in compliance with GDPR Chapter V, using standard contractual clauses or adequacy decisions where applicable.

11. Changes to This Policy

11.1. We may update this Privacy Policy from time to time to reflect changes in our practices, technology, legal requirements, or other factors. The "Last Updated" date at the top of this Policy indicates when the most recent changes were made.

11.2. For material changes to this Policy, we will notify you by:

• Posting a prominent notice on the Platform;

• Sending an email to the address associated with your account;

• Requiring acknowledgement of the updated Policy on your next login (for significant changes).

  11.3. Your continued use of the Platform after the effective date of any changes constitutes your acceptance of the revised Policy.

  11.4. We encourage you to review this Policy periodically to stay informed about how we protect your data.

  11.5. Internal re-validation log (held-text discipline). As an internal compliance practice, Doorkee re-validates regulator-readable text in this Policy that describes a surface still under active implementation, to ensure the disclosed processing matches the live code path. The most recent re-validation: 2026-05-02 — three held markers in §2.4 and §7.3a/§7.3b were reviewed against current implementation. The §2.4 disclosure of optional offer notes was confirmed accurate against the data model and the marker was retired. The §7.3a and §7.3b disclosures of the server-side analytics identifier were rewritten to describe both the keyed HMAC-SHA-256 path (active when the server-side secret is set in production) and the transitional unkeyed SHA-256 fallback path (active during the grace period before that secret is set), so the disclosed processing is accurate in both states.

12. Data Protection Officer

DoorKee FZ-LLC has appointed an internal Data Protection Officer responsible for UAE PDPL duties under Article 24, including breach response, data-subject request (DSAR) handling, annual audit coordination, and liaison with the UAE Data Office.

• Data Protection Officer: Hemanth [last name]
• Primary contact: dpo@doorkee.co
• Secondary contact (alias): privacy@doorkee.co
• Response SLA: 30 days (per UAE PDPL).

For urgent breach notifications or data-subject requests, please email the primary contact with the subject line "PDPL — [Your Right / Issue]".

13. Contact Information

If you have any questions, concerns, or requests regarding this Privacy Policy or our data practices, you may contact us at:

DoorKee FZ-LLC FOAM0424, Compass Building, Al Shohada Road Al Hamra Industrial Zone-FZ, Ras Al Khaimah, United Arab Emirates

• General Support: support@doorkee.co
• Privacy Contact: privacy@doorkee.co
• Website: www.doorkee.co

For data privacy requests, please include:

• Your full name and email address associated with your account;
• A clear description of your request;
• Any relevant details to help us locate your data.

We will acknowledge your request within 5 business days and provide a substantive response within 30 days.

14. Definitions

For the purposes of this Policy:

• "Personal data" means any data relating to an identified or identifiable natural person, as defined by UAE Federal Decree-Law No. 45 of 2021;
• "Processing" means any operation performed on personal data, including collection, storage, use, disclosure, transfer, or deletion;
• "Controller" means DoorKee FZ-LLC, which determines the purposes and means of processing personal data;
• "Processor" means any third party that processes personal data on our behalf (e.g., Stripe, Resend, Supabase);
• "Platform" means the Doorkee website (www.doorkee.co), mobile applications, and all related services.

15. Right to Erasure (DSAR Procedure)

The data-subject-request (DSAR) surface described in this section is on Doorkee's near-term roadmap (Sprint 5 of the Doorkee Dara Remediation Program). We are publishing this policy in advance of the live rollout for transparency, so that users and regulators can review the intended procedure before it ships. Verbs throughout this section are written in the future-conditional tense to reflect that posture; once the surface is live, this Policy will be amended to present-tense and re-dated.

15.1. Under UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data ("PDPL") Article 17, you will have the right to request the erasure of your personal data held by Doorkee, subject to the statutory retention obligations described in §15.5. This section explains how you will exercise that right and what will happen after you submit a request. The procedure will be implemented in compliance with PDPL Article 17, the data-subject-request response window in PDPL Articles 18–22, and (for self-declared residents of the European Economic Area) the equivalent rights under GDPR Articles 15–22.

15.2. How to submit a request. You will sign in to your Doorkee account and go to /account/data-rights. You will be asked to re-authenticate by entering your password (or by re-confirming your OAuth identity if you signed in via Google or Apple) within a five-minute confirmation window. After re-authentication, you will submit the request form. We will acknowledge every valid request by email within twenty-four hours.

15.3. Soft-delete grace window. From the moment your request is acknowledged, your account will enter a seven-day soft-delete grace window. During this window, your data will be hidden from all Platform surfaces but will not yet be erased from our database. If you change your mind, you will be able to cancel the request at any time during the seven days by signing back in (we will accept your password during this window) and clicking "Cancel Erasure Request" in the same /account/data-rights screen. A confirmation email containing a cancellation link will also be sent at acknowledgement.

15.4. Hard-erasure SLA. If the request is not cancelled within the seven-day grace window, Doorkee will proceed to hard-erase your data on the eighth day. We will complete the full erasure (including the third-party processor cascade described in §15.6 below) within thirty days of the original submission, in line with PDPL Article 18's statutory thirty-day response window.

15.5. AML / Commercial-Code carve-out. Certain financial and commercial records are subject to statutory retention obligations that override an erasure request:

• Financial records (payment transactions, refund events) — retained for five years under UAE Federal Decree-Law No. 20 of 2018 (AML-CFT) Article 16 and UAE Federal Decree-Law No. 32 of 2021 (Commercial Companies Law) Article 26;
• Identity verification records (KYC) — retained for five years after the business relationship ends, under UAE Federal Decree-Law No. 20 of 2018 Article 16;
• Lease and rental-transaction records — retained for five years under UAE Federal Decree-Law No. 26 of 2007 and Dubai Law No. 85 of 2006 (RERA broker-licence retention obligation).

For these records, your personal-data fields (name, email, phone, document images, document numbers) will be anonymised in place — we will replace them with non-identifying sentinels so that the row cannot be re-linked to you — but the row itself will be retained for the statutory window. The non-personal fields (transaction amount, status, dates) will be kept as required for audit. You will receive a final email confirming what was deleted, what was anonymised, and which records remained under the carve-out.

15.6. Third-party processor cascade. When your request is hard-erased, Doorkee will signal deletion to the third-party services we use to deliver the Platform. The cascade will cover eleven processors:

| Processor | Purpose | Erasure mechanism | | ------------------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Stripe | Payment processing | Customer record retained 5 years per AML/CFT floor; non-financial PII anonymised via Doorkee database scrub | | Anthropic | AI Concierge (Claude models) | No-op — system-prompt-only architecture; no PII transmitted | | OpenAI | AI Concierge (GPT models) | No-op — system-prompt-only; no PII transmitted | | Google (Gemini) | AI Concierge (Gemini models) | No-op — system-prompt-only; no PII transmitted | | PostHog Inc. | Product analytics | Distinct-id deletion via Personal Data API ($delete_user) | | Sentry | Error monitoring | User-deletion API call; remaining events expire under 90-day default retention | | Resend | Transactional email delivery | Per-recipient contact deletion across audiences; transactional log purge | | Inngest | Background event queue | Event-log scrub via Inngest user-deletion API | | Twilio | SMS delivery | Message-log deletion via Messages API | | Meta WhatsApp | WhatsApp messaging | Conversation deletion via Cloud API; subject to Meta-side retention floors that we cannot override | | Supabase Auth | Authentication and session store | Auth-user deletion via service-role client; cascades to identities and sessions |

Where a processor has a statutory or platform-side retention floor that we cannot override (Stripe AML, Meta WhatsApp metadata floor), we will record this in our internal cascade audit trail and disclose it in the final confirmation email. We will not claim erasure for data we cannot reach.

15.7. Cooperation and escalation. If a third-party processor fails to comply with our deletion request after five retry attempts, we will escalate the matter to the UAE Data Office on your behalf, in line with PDPL Article 23's regulator-cooperation obligation. You will be informed of any such escalation in the final confirmation email.

15.8. Right to object, restrict, and access. This section will also cover requests under PDPL Articles 15 (right of access), 16 (right to rectification), 19 (right to object), and 20 (right to data portability). Self-declared EEA residents will additionally be able to request a structured, machine-readable export of their data under GDPR Article 20; the export will be delivered as a JSON file via a single-use download link emailed to the account address. All such requests will be handled through the same /account/data-rights form and the same thirty-day SLA.

15.9. Contact for DSARs. You will submit erasure, access, rectification, objection, and portability requests through /account/data-rights after signing in. For escalations or for requests that cannot be made through the in-product form (for example, if you have lost access to your account), you will contact the Data Protection Officer at dpo@doorkee.co with the subject line "PDPL — [Your Right]". The DPO will acknowledge within five business days and will provide a substantive response within thirty days.

16. Regulatory-Update Monitoring

The regulatory-update monitoring surface described in this section is on Doorkee's near-term roadmap (Sprint 5 of the Doorkee Dara Remediation Program). We are publishing this policy in advance of the live rollout for transparency, so that users and regulators can review the intended posture before it ships. Verbs throughout this section are written in the future-conditional tense to reflect that posture; once the surface is live, this Policy will be amended to present-tense and re-dated.

16.1. To ensure that Doorkee's policies and platform rules stay aligned with UAE regulatory updates, we will operate a regulatory-update monitoring surface. This section explains what the surface will do, what data it will process, and (importantly) what data it will not process.

16.2. Legal basis. We have chosen a hash-only architecture for this surface to keep regulator content outside our processing scope. UAE Federal Decree-Law No. 38 of 2021 (Electronic Transactions and Trust Services) is the regime under which the integrity of cryptographic fingerprints is generally regulated in the UAE; PDPL Article 1 is satisfied because the SHA-256 hash is pseudonymised and unrecoverable.

16.3. Procedure. Once per week, an automated job will fetch the public response body of a fixed allowlist of five UAE regulatory pages (currently: the Dubai Land Department, the Real Estate Regulatory Agency (RERA), the Real Estate Dispute Settlement Centre (RDSC), the Ejari electronic-tenancy-contract registry, and the DLD eServices portal). For each fetched page, we will compute and store a SHA-256 hash of the response body — the hash only. We will not store the response body itself, we will not parse the body for personal data, and we will not transmit the body to any third party.

16.4. Hash-diff alerts. When the weekly hash differs from the previous week's hash, an internal admin notification will fire. A Doorkee staff member will then manually review the regulatory page, decide whether the change affects Doorkee's policies or platform rules, and (if so) update the relevant Doorkee internal documentation. No automated rule deployment will occur as a result of a hash diff — every policy change will be human-reviewed.

16.5. No personal data, no user data shared. This surface will not process personal data and will not share any user data with regulators. It will be a one-way, read-only fetch of public government pages. Because we will store only the SHA-256 hash of each fetched response body, the hash will be unrecoverable for plaintext content under standard cryptographic assumptions, and the surface will fall outside the identifying-data scope of PDPL Article 1. We disclose this surface in this Policy purely for transparency about our intended regulatory-monitoring posture.

17. Lifecycle Email and WhatsApp Messaging (M27)

The lifecycle email and WhatsApp messaging surfaces described in this section are on Doorkee's near-term roadmap (Sprint 6 of the Doorkee Dara Remediation Program). We are publishing this policy in advance of the live rollout for transparency, so that users and regulators can review the intended posture before it ships. Verbs throughout this section are written in the future-conditional tense to reflect that posture; once each surface is live, this Policy will be amended to present-tense and re-dated.

17.1. Scope. This section discloses two communication surfaces that will ship in Sprint 6: (a) lifecycle email — periodic, marketing-class email sent to users who have granted explicit marketing consent; and (b) WhatsApp messaging — inbound and outbound conversational messaging via the WhatsApp Business Cloud API. Both surfaces operate within the existing eleven-processor cascade (see §15.6) and do not introduce a twelfth processor.

17.2. Lifecycle email — lawful basis. Lifecycle email will be sent under UAE Federal Decree-Law No. 45 of 2021 ("PDPL") Article 9 (explicit consent for marketing communications). Recipients who have not granted marketing consent — that is, who have left the marketing toggle off in the cookie banner described in §7.3 (the PDPL Art. 6 safe default) — will be excluded from the lifecycle send list at the handler level. The marketing toggle is the single, authoritative gate; it is enforced by joining the EmailPreference and PdplConsentRecord records before any send.

17.3. Lifecycle email — sender identity and signature. Lifecycle emails will carry the signature "— Dara at Doorkee Concierge" as the closing line above the unsubscribe footer. This signature distinguishes lifecycle communications (consent-based, marketing-class) from transactional communications (legitimate-interest, contract-performance), which retain the existing "— The Doorkee Team" sign-off. The signature is fixed by the handler and cannot be customised per-message.

17.4. Lifecycle email — opt-out. Three independent opt-out paths will be available, in line with PDPL Article 13 (right to object to processing for direct marketing purposes):

• One-click unsubscribe via the List-Unsubscribe HMAC-tokenised header in every lifecycle email.
• In-product preference toggle at /account/communications, which flips your PdplConsentRecord.marketing flag to false and takes effect on the next handler run (within twenty-four hours).
• DPO email at dpo@doorkee.co — see §12.

Withdrawing marketing consent does not affect transactional emails (payment receipts, KYC confirmations, offer notifications), which we will continue to send under the contract-performance lawful basis described in §3.8.

17.5. WhatsApp messaging — operator and lawful basis. Outbound and inbound WhatsApp messages will be transported via Twilio and the Meta WhatsApp Business Cloud API. Doorkee will operate from a UAE-licensed Meta WhatsApp business number for messages directed to UAE users. Inbound user messages and Doorkee replies will be processed under PDPL Art. 4 lawful-basis grounds (contract performance and operational reliability — the user has initiated a conversation about a Doorkee transaction). Outbound transactional notices (offer status, visit reminders) will be processed under the same Art. 4 contract-performance basis. Outbound WhatsApp messages that fall in the marketing class (currently none in v1) would require Art. 9 explicit consent.

17.6. WhatsApp messaging — Meta-side retention floor. Meta retains WhatsApp message metadata (timestamps, delivery status, message identifiers) on its platform for periods that Doorkee cannot override. On a verified DSAR, Doorkee will issue the Cloud API conversation-deletion call and record the result in the cascade audit trail; where Meta declines to honour the deletion within Meta's own retention floor, Doorkee will disclose the floor to you in the final DSAR confirmation email (per §15.6).

17.7. WhatsApp messaging — opt-out. You may opt out of all WhatsApp communications from Doorkee at any time by replying STOP, UNSUBSCRIBE, or the Arabic equivalents (إيقاف, إلغاء, توقف) to any Doorkee WhatsApp message. You may also contact the DPO at dpo@doorkee.co to request opt-out. Acknowledgements are sent in the language of your opt-out message (English or Arabic). Any of these keywords will write a tombstone to the User.channelOptOuts JSON field and suppress all future Doorkee-originated WhatsApp messages to your number until you re-opt-in by replying START, SUBSCRIBE, بدء, or اشتراك.

17.8. DSAR cascade reach. Lifecycle email and WhatsApp transmissions are inside the eleven-processor cascade described in §15.6. On a verified DSAR for erasure, the cascade will signal deletion to Resend Inc. (transactional + lifecycle email logs) and to Meta WhatsApp (Cloud API conversation history) per the row-by-row mechanisms in §15.6. No new processor will be added by M27.

18. DLD-Comparables Surface — Defensive-Internal Posture (M28)

The DLD-comparables surface described in this section is on Doorkee's near-term roadmap (Sprint 6 of the Doorkee Dara Remediation Program). We are publishing this policy in advance of the live rollout for transparency, so that users and regulators can review the intended posture before it ships. Verbs throughout this section are written in the future-conditional tense to reflect that posture; once the surface is live, this Policy will be amended to present-tense and re-dated.

18.1. Scope. Sprint 6 will introduce a Dubai Land Department (DLD) comparables ladder that Dara will consult internally when generating valuation responses to owners and tenants. This section discloses what the surface will do and (importantly) what it will not do.

18.2. Internal-only in v1. The DLD-comparables ladder will be internal to Doorkee in version 1. The user-facing valuation response will not name DLD as a source, will not include a DLD permit number, will not include a DLD URL or hyperlink, and will not contain prose such as "per Dubai Land Department". If a user asks where a valuation comes from, Dara will respond with the existing fallback disclosure (verifiable transactions on Doorkee plus RERA-published rent indices). DLD will not be named in v1 user-facing copy.

18.3. Why internal-only. UAE Federal Decree-Law No. 38 of 2021 governs electronic transactions and digital trust. The DLD eServices Terms of Service have not yet been legally cleared by external counsel for read-and-cite use in a third-party rental platform. Until counsel clearance is obtained, Doorkee will preserve the wedge value of better internal valuations while deferring the citation surface — a defensive posture analogous to the hash-only architecture used for regulatory-update monitoring (§16).

18.4. No automated scraping. Doorkee will not scrape DLD eServices. The DLD-comparables corpus will be ingested out-of-band by a Doorkee staff member from publicly published DLD transaction summaries. The Dubai Land Department's public response bodies will not be persisted; only derived fingerprints (community, unit type, beds, area band) and a SHA-256-truncated hash of each comparable will be retained. This preserves the zero-scraping posture required by Decree-Law 38/2021.

18.5. No personal data transmitted. The DLD-comparables surface will not transmit personal data to DLD or to any other third party. The internal lookup that informs Dara's valuation will key on a property fingerprint hash, not on the user's identity. Telemetry events emitted by the lookup (concierge.dld_comparables_lookup — see spec.md §10.8.1) will carry the hash only, never a DLD URL, permit number, or raw address.

18.6. Sprint 7 deferral path. If external counsel clears the DLD eServices Terms of Service for read-and-cite use by Sprint 7 open, Doorkee will ship M28 v2 with a citation surface — user-facing prose will name DLD as a source, will include a permit number when available, and will add a "verify on dld.gov.ae" link. This Policy will be amended to disclose the citation surface before any user-facing change ships. Until that amendment lands, the v1 internal-only posture above is binding.

This Privacy Policy is effective as of 19 March 2026.

Doorkee -- UAE's first outcome-driven rental platform.