> For the complete documentation index, see [llms.txt](https://popin.gitbook.io/popin-developer-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://popin.gitbook.io/popin-developer-hub/dpdp-compliant-widget-integration-with-zero-pii-exposure.md).

# DPDP-Compliant Widget Integration with Zero PII Exposure

This guide describes a **privacy-first integration model** for real-time calling widgets, designed to ensure **no personally identifiable information (PII)** is transmitted to or stored by the widget provider.

The architecture aligns with India’s **Digital Personal Data Protection (DPDP) Act, 2023**, while delivering a seamless calling experience.

***

### Key Features

* Personal data is collected and retained entirely within the organization’s systems.
* The widget provider receives only a **non-identifiable reference ID**.
* Call recordings are generated and stored **directly in the organization’s own storage infrastructure**.
* The widget provider does **not** process, proxy, or retain personal data or recordings.

***

### Design Principles

1. **Data Minimization**\
   Only the minimum data required to initiate a call is shared, and it is non-identifiable.
2. **Clear Role Separation**\
   The organization is the **Data Fiduciary**. The widget provider does not act as a Data Fiduciary or Data Processor.
3. **Direct Data Ownership**\
   Call recordings are fully owned, stored, and governed by the organization.
4. **Reduced Compliance Surface**\
   By eliminating PII handling, the widget provider largely remains outside the scope of DPDP obligations.

***

### End-to-End Integration Flow

#### 1. Customer Data Collection

Customer information (e.g., name, phone number, or email) is collected **within the organization’s website or app**:

* Data is collected with appropriate consent
* All personal data remains internal
* The calling widget is **not involved** at this stage

```
Customer
   |
   |  (Name, Phone / Email)
   v
Organization Website / App
```

***

#### 2. Reference ID Generation

The organization’s backend or CRM system generates a **unique, non-PII reference ID**:

* Contains **no personal data**
* Cannot be reverse-engineered externally
* Personal data remains internal

<figure><img src="/files/r0BKQTzmHlHIpiSTePSo" alt=""><figcaption></figcaption></figure>

***

#### 3. Widget Invocation Without PII

The reference ID is passed to the widget during initialization.

For **Popin-based integrations**:

```javascript
Popin('captured', {
    name: "customer",
    mobile: generated_id
});
```

**Notes:**

* `generated_id` is a non-PII reference ID.
* `name` is a static placeholder; it does **not** contain real personal data.
* The reference ID is used only for internal session correlation.

```
Website / App
     |
     |  Reference ID (No PII)
     v
Calling Widget (Popin)
     |
     v
Call Screen
```

***

### Call Handling and Recording

#### Live Call Session

* Call established without sharing personal data.
* Widget provider sees **only the reference ID**, not customer identity.
* No PII in signaling, metadata, or media streams.

#### Call Recording: Direct-to-Storage Model

Recordings are stored **directly in the organization’s Amazon S3 bucket**. The widget provider **does not store or proxy recordings**.

**Storage Setup**

1. Create an **S3 bucket** dedicated to call recordings.
2. Create an **IAM user** with the following permission:

```
s3:PutObject
```

* Ensures recordings can be written securely.
* Does **not** grant read or delete access.

**Credentials Provided to Widget**

* **AWS\_ACCESS\_KEY\_ID** – IAM user access key
* **AWS\_SECRET\_ACCESS\_KEY** – IAM user secret key
* **BUCKET\_NAME** – S3 bucket name
* **REGION** – Bucket’s AWS region

<figure><img src="/files/FHgvHGtVcBiSLHMj7cZK" alt=""><figcaption></figcaption></figure>

**Guarantees:**

* Widget provider cannot access, retrieve, or replay recordings.
* Retention, deletion, and access are **fully controlled by the organization**.

<figure><img src="/files/xKAo5iCMn7vq6KO6JgD6" alt=""><figcaption></figcaption></figure>

***

### DPDP Compliance Analysis

| Entity               | DPDP Role                                     |
| -------------------- | --------------------------------------------- |
| Organization         | Data Fiduciary                                |
| Widget Provider      | No personal data role                         |
| Media Infrastructure | Technical service provider (no PII ownership) |

**Compliance Outcomes:**

* ✅ Widget provider does **not** handle personal data
* ✅ Call recordings remain under the organization’s control
* ✅ Simplified consent, retention, and deletion workflows
* ✅ Reduced audit, contractual, and regulatory risk

***

### Benefits

This architecture is ideal for:

* Regulated industries (financial services, healthcare, enterprise SaaS)
* Organizations with strict data ownership and residency requirements
* Teams minimizing third-party exposure under DPDP

**Summary:**

* Zero PII exposure to the widget provider
* Reference-ID–based widget invocation using Popin
* Direct ownership and storage of call recordings in Amazon S3
* Clear responsibility separation and reduced compliance scope

This model provides a **scalable, enterprise-ready calling experience** built on **privacy by design**.