Privacy Policy

This Privacy Policy explains how Apexnova Private Limited (“Apexnova,” “Deeplinkly,” “we,” “us,” or “our”) handles personal data through:

• deeplinkly.com, deeplinkly.in, and deeplinkly.io;
• the Deeplinkly dashboard, APIs, SDKs, link-routing and attribution services;
• dplink.app and customer-reserved subdomains beneath it; and
• account, service, support, billing, legal, and marketing email sent by us.

The Services are offered for business and professional use. This policy covers people who operate customer accounts, visit our websites or links, communicate with us, and use apps that integrate Deeplinkly.

1. When Deeplinkly is controller and when it is processor

Deeplinkly determines why and how personal data is processed for its own websites, accounts, billing, security, support, service communications, marketing, and business operations. For that processing, Deeplinkly acts as a controller, Data Fiduciary, business, or equivalent role under applicable law.

When a customer uses Deeplinkly in its app, links, campaigns, webhooks, or other integrations, the customer normally determines why end-user data is processed and how the Services are configured. For that processing, the customer acts as controller or business and Deeplinkly acts as its processor or service provider, except where applicable law assigns a different role.

2. Personal data we handle

The data actually processed depends on the Services used, the customer's configuration, the device and platform, available signals, and choices made by the customer and end user.

Website, account, support, and billing data

We may process:

• name, email address, email-verification state, account ID, avatar, organisation, role, team or project membership, and account settings;
• authentication, session, CSRF, login-state, invitation, API-key, and security data;
• for Google or GitHub login, name, email, avatar, provider ID, OAuth tokens, and login metadata;
• optional contact details, notification preferences, and information entered in account, sales, demo, survey, support, or contact forms;
• billing name and address, plan, invoice information, payment or transaction ID, status, amount, currency, card brand, last four digits, and card expiry;
• support messages, attachments, and other communications;
• service and marketing email content, delivery events, bounce, complaint, unsubscribe, and suppression information;
• Firebase installation and analytics identifiers, internal Deeplinkly user ID, full page location, page path and title, signup or login method, and purchase value, currency, transaction ID, and items;
• public IP address, user agent, request headers, full requested URLs and query parameters, request time, response status, and API, access, and error logs; and
• dashboard activity, project configuration, links, campaigns, reports, exports, and integrations.

Stripe or Razorpay collects complete payment credentials through its own payment interface. Deeplinkly does not retain complete card numbers, CVVs, OTPs, PINs, or bank-login credentials.

Link clicks and dplink.app

Customers may reserve available subdomains beneath dplink.app for their links and campaigns. When a person requests a Deeplinkly link or customer-reserved subdomain, we may process the domain and subdomain, requested URL and query parameters, link code or click identifier, redirect destination, campaign or referral parameters, public IP address, user agent and request headers, timestamp, response status, and related access or error logs.

The customer controls the label, links, parameters, content, and destinations used through its reserved subdomain. Visitors should also review the privacy notice of the customer whose link or app they use.

SDK, API, attribution, and event data

Depending on configuration and platform availability, customer apps may send:

• Deeplinkly device, installation, request, session, link, and click identifiers;
• an optional customer-defined user identifier;
• identifying details the customer's app chooses to supply through the SDK's user-data call: email address, phone number, first and last name, date of birth, gender, street, city, state, postal code, and country;
• an open custom-data field of up to ten customer-defined key and value pairs, whose keys and contents the customer chooses and Deeplinkly does not interpret;
• a push-notification token and the provider that issued it, where the customer enables uninstall measurement;
• consent state recorded through the SDK's consent call;
• conditional platform identifiers such as IDFV, App Set ID, Android ID, IDFA, or Google Advertising ID, subject to platform availability, configuration, and applicable permission or tracking choices;
• app, SDK, operating-system, device, hardware, screen, language, timezone, carrier, network, local-IP, and emulator-related signals;
• install time, first-open, app-open, session, and attribution state;
• install-referrer data, campaign and UTM values, supported advertising click identifiers, Meta Install Referrer data, and Apple attribution postbacks;
• link metadata, deep-link parameters, and a supported link URL read through an enabled iOS pasteboard flow;
• event names, event properties, conversion data, and other values configured by the customer; and
• error messages, stack traces, request context, retry information, and other diagnostics.

The SDK's Full collection level is currently the default. Customers can configure a more limited level. Advertising identifiers are not collected in every installation: their availability depends on the platform, customer configuration, included dependencies, and the user's platform choices.

The identifying details and the custom-data field listed above differ in kind from the rest of that list. They are not observations about a device: they are personal data the customer's app already held and chose to send, so Deeplinkly holds directly identifying data on the customer's behalf rather than only pseudonymous identifiers. They are classified at the SDK's most limited enrichment level, which means they are sent at every collection level except the level that disables enrichment entirely. They travel over TLS and are held encrypted at rest. They are not hashed in storage by default, and are hashed when a conversion is forwarded to an advertising destination.

A customer can enable on-device hashing, which is off unless the customer turns it on. With it enabled, the email address, phone number, and first and last name are hashed on the device and those plaintext values do not reach Deeplinkly. Gender, date of birth, and country are not hashed in that mode, because their ranges of possible values are small enough that a hash of them could be reversed by trying each one. These fields remain within scope for access and erasure requests whether or not they are hashed.

Customer-controlled identifiers, event properties, URLs, query parameters, metadata, referrer values, messages, and diagnostics can contain personal data chosen by the customer. The lawful basis for supplying each of these fields is the customer's to establish, not Deeplinkly's. Customers are responsible for avoiding unnecessary or prohibited data, including special-category data in the open custom-data field, and for giving required notices and obtaining required consent.

Functional requests and privacy controls

Customers can disable SDK reporting and can invoke the SDK's local privacy reset as part of their end-user privacy flow. Disabling reporting removes pending reporting retries and prevents new reporting, but link resolution and generation remain available. Those functional requests still transmit the tenant key, requested link or generation data, public IP address, and ordinary network metadata, but omit the SDK's stable Deeplinkly identifier and customer-defined user identifier while reporting is disabled.

The SDK's most limited enrichment setting minimises catalogue data but is not a complete network opt-out: functional requests and customer-configured events may still transmit data. A local privacy reset removes Deeplinkly identifiers and other Deeplinkly data stored locally on that device and leaves reporting disabled. Clearing the identifying details is a separate call that does reach the Service, and customers can run an erasure themselves; both are described in section 9.

Data received from other sources

We may receive limited profile and authentication data from Google or GitHub, payment and fraud-prevention information from Stripe or Razorpay, campaign and attribution information from supported platforms, and data from integrations deliberately enabled by the customer.

3. Why we process personal data

We process personal data to:

• create and operate accounts and provide the Services;
• route links and provide deterministic or platform-supported attribution, reporting, exports, events, and customer-enabled integrations;
• maintain installation and session state;
• process invoices and payments;
• provide support and send account, billing, security, legal, and service communications;
• send marketing where permitted and manage unsubscribe and suppression choices;
• diagnose compatibility, reliability, and technical errors;
• protect accounts and Services, enforce agreements, and investigate misuse;
• comply with law and establish, exercise, or defend legal claims; and
• create de-identified product analytics and benchmarks.

4. Aggregated and de-identified data

We may aggregate or de-identify data across customers to analyse the product, show benchmarks to customers, and publish industry benchmarks. We do this only where neither an individual nor an individual customer can reasonably be identified. We do not attempt to re-identify that data and do not name a customer without its prior written consent.

Genuinely de-identified benchmark and product-analytics data may be retained indefinitely.

5. Legal bases

Where EU or UK data-protection law applies to processing for which Deeplinkly is controller, we rely on the following bases as appropriate:

Where Deeplinkly acts as processor, the customer determines the applicable legal basis and gives Deeplinkly documented instructions. Processing under Indian law is conducted on the grounds and subject to duties applicable at the relevant time, including as provisions of the Digital Personal Data Protection Act, 2023 and its rules come into force.

6. Cookies, analytics, and email choices

The websites and dashboard use storage and similar technologies needed for authentication, sessions, security, and user preferences. Firebase Analytics is used for website and dashboard analytics and processes the analytics information described in section 2.

Where consent is required, Firebase Analytics will not load until the visitor chooses to allow non-essential analytics. A visitor can later withdraw consent through the available consent settings. Withholding analytics consent does not prevent use of essential account or service functions.

We use AWS SES to send automated account, verification, password-reset, billing, service, and marketing email. Messages may use deeplinkly.com, deeplinkly.in, or deeplinkly.io. Google Workspace is used for company mailboxes and person-to-person correspondence.

Marketing may be sent to customers and people who requested or consented to it. We do not use purchased, rented, or scraped email lists. Marketing messages include a method to unsubscribe. Opting out does not stop essential account, billing, security, legal, or service messages.

7. Who receives personal data

We may disclose personal data to:

• the customer whose app, link, project, or integration generated the data;
• integrations and recipients deliberately enabled by that customer;
• Amazon Web Services, including Mumbai-region hosting and storage, CloudFront delivery, and SES email delivery;
• ZeroBuffer.io for public static-asset and image delivery;
• Google Firebase for website and dashboard analytics;
• Google Workspace for company email;
• Google OAuth and GitHub OAuth when an account user chooses that login method;
• Stripe for payments by customers outside India and Razorpay for payments by customers in India;
• Sentry for application error monitoring, configured not to receive SDK attribution or customer-event data;
• professional advisers under confidentiality obligations;
• authorities and other recipients where disclosure is legally required; and
• a buyer, successor, or adviser involved in a merger, financing, reorganisation, or sale of the relevant business, subject to appropriate safeguards.

GitHub is used for source-code hosting and CI and is configured not to receive production customer data.

We do not sell personal data. We do not disclose customer-app end-user data to another customer. Except for AWS hosting and a recipient or integration selected by the customer, the operational vendors above do not receive SDK attribution or customer-event data.

8. Storage and international transfers

Deeplinkly is established in India. Its standard backend, databases, SDK attribution data, customer-event and project data, and backups are hosted in the AWS Mumbai region (ap-south-1). CloudFront is used for delivery and does not cache private customer data. US or EU data residency may be offered under a separate agreement.

Some vendors and customer-selected integrations may process data in other countries. Where a restricted transfer from the EEA or UK requires contractual safeguards, Deeplinkly uses the applicable European Commission Standard Contractual Clauses and UK transfer addendum or another lawful mechanism. A copy of applicable safeguards may be requested from legal@deeplinkly.com, subject to appropriate redactions.

9. Retention, closure, and deletion

Following a verified deletion request, eligible data is deleted from active production systems within 30 days. Deleted data may remain in database backups for up to another 31 days before those backup copies expire. Invoice, tax, dispute, security, and other legally required records may be kept longer.

Requests for expedited deletion or special handling needed for legal compliance may be sent to legal@deeplinkly.com. We consider them through a reasonable manual review, subject to technical feasibility, applicable law, and retention obligations.

An app publisher can invoke the SDK's local privacy reset to remove Deeplinkly data stored locally on the current device. That local action does not by itself delete records already held on Deeplinkly's servers.

A separate SDK call clears the identifying details and custom-data field described in section 2. Unlike the local privacy reset, it both erases those values on the device and instructs the Service to erase the stored values, and it is re-sent until it is delivered if the device is offline when it is called.

A customer can also erase an identified person's data directly, without asking Deeplinkly to act for it, using the privacy controls in its dashboard or the corresponding API. A subject can be identified by custom user ID, device ID, email address, or Deeplinkly user ID, singly or as a batch, and each request is recorded in an audit trail the customer can retrieve as evidence that it acted. An erasure run this way does not reach database snapshots taken before the request, data already forwarded to an advertising destination on the customer's behalf, or the customer's own exports and warehouse copies.

10. Security

Deeplinkly uses reasonable technical and organisational safeguards appropriate to the nature of the data and Services. No method of transmission or storage is completely secure.

Report a suspected security or privacy issue to legal@deeplinkly.com.

11. Privacy rights and requests

Depending on applicable law, a person may have rights to request access, correction, deletion, restriction, objection, portability, or withdrawal of consent, and to complain to a competent privacy authority. These rights may be subject to legal conditions and exceptions.

To make a request concerning data for which Deeplinkly is controller, email legal@deeplinkly.com. We may request information reasonably needed to verify identity and locate relevant records. Requests are handled manually, and we respond within the period required by applicable law rather than promising a shorter voluntary period.

If you use an app or link operated by a Deeplinkly customer

Contact the app publisher or link operator first where possible. That customer usually controls the data, can identify the relevant app, project, and records, and can carry out an erasure itself through the privacy controls described in section 9 without waiting for us. You may also contact legal@deeplinkly.com with the app or link and an available identifier, such as a Deeplinkly device ID, custom user ID, advertising ID, or click ID. We will verify the supplied information, identify and coordinate with the relevant customer, and handle the request manually.

12. Children and customer responsibilities

Deeplinkly does not impose a universal account-age cutoff or prohibit customers from using the Services in apps used by children. Each customer is responsible for determining whether and how its app may lawfully process children's data, including applicable age, parental-notice, consent, platform, and child-safety requirements governing the customer and its users.

This allocation does not remove obligations that applicable law places directly on Deeplinkly. If you believe children's data has been processed unlawfully, contact legal@deeplinkly.com and identify the relevant app or link.

13. Changes to this policy

We may update this policy. We will provide reasonable advance notice of a material change through email, the dashboard, or the website. A change required by law or reasonably needed to address an urgent security, fraud, or abuse risk may take effect sooner. The effective date above identifies the current version.

14. Contact and grievance handling

Privacy requests and legal notices may be sent to legal@deeplinkly.com.