#Transferring personal data to an external CRM

Status: Planned. Connecting an external CRM, the declarations log, and the disclosure log are not implemented: today there is no transfer log. This page describes the procedure adopted in the design. This is a technical description, not legal advice and not a guarantee of compliance with the law. The terms of personal data processing are set by your agreement with us and the laws of your country; for a legal assessment, consult your own lawyer.

Leads and contacts contain personal data (PII): a name, an email, a phone number, a history of inquiries. By connecting an external CRM, you authorize the transfer of this data outside the platform. This page explains the roles of the parties, what is recorded at connection time, how data disclosures work, and how a thin event payload differs from a full one.

Access: the scopes that yield PII are leads:read, conversations:read, and others from the description of keys. Paid: no. PII: yes. Cells: data lives in the database of the cell where your key works; see Cells and data.

#Roles of the parties

Transferring data to your CRM is your decision as the controller. We record the fact of the connection, the hosting country, and the basis you stated.

#What you specify when connecting

When connecting an external CRM as an integration, you will need:

This information is written to the declarations log: the integration, fields, basis, country, and time.

#The RU cell: mandatory conditions

The endpoints with PII (conversations:*, leads:*) are open on all three cells. The RU cell's customer data is stored in Russia; a cell's key does not by itself guarantee that the data will stay in Russia, because it can be fetched from a Russian address and forwarded on. Therefore the following conditions apply to keys with PII scopes in the RU cell:

In the RU cell, PII is transferred only to recipients hosted in the Russian Federation. If a hosting country other than the Russian Federation is specified when connecting the integration:

• the conversations:* and leads:* scopes and the include_pii flag are not granted for this integration;
• a request to grant them ends with the pii_transfer_not_allowed error (HTTP 403, error catalog);
• to receive PII, host the receiving system in the Russian Federation, or do not request PII scopes and include_pii: thin events and requests without PII remain available;
• the hosting country is written to the declarations log.

#The disclosure log

Every disclosure of PII is written to the log without the values themselves: who (the integration and key), what (the data type), how many records, when. The following count as a disclosure:

• an API response that contains a contact (for example, GET /leads);
• a webhook event with include_pii: true.

The log helps answer the question "what data left for an external system and when" without creating a second copy of the data itself. The tenant sees the log in the dashboard and through the GET /disclosures request. Entries are kept for 3 years.

#Event payloads: thin and full

By default, webhook events are "thin": a type, IDs, and a version, with no PII. For example, lead.created contains lead_id, but not the name and phone. To get the content, the recipient itself makes a GET /leads/{id} request with its own key. That way PII does not go to an address that has not proved it holds a key.

The include_pii flag is set on a subscription (Webhooks) and is allowed only for lead.*, contact.*, and conversation.* events. The integration must have leads:read and/or conversations:read. Enabling it is noted in the declarations log, and each such delivery in the disclosure log. The message.created event never contains the message text: it is requested separately (with the conversations:read permission). Webhooks of the old format passed the text of the customer's messages in events; the new scheme does not.

#What is masked before reaching models

When a model scores a lead or the AI seller works with it, phone numbers, emails, card numbers, messenger accounts, passport data, SNILS, INN, names, and addresses are removed from the conversation text before it is sent to the model and replaced with placeholders. This is protection on the AI side; it does not apply to the data you receive through the API. More: Lead scoring.

The strategist cannot see PII by construction: only aggregates are available to it.

#How to limit who receives data

• Issue keys with a minimal set of scopes: if an integration does not need leads, do not give it leads:read.
• For an integration in the RU cell, an allowlist of IP addresses is required for PII scopes; on the other cells it is also worth setting one.
• Separate keys: one key for reading leads into an external CRM, another for publishing articles.
• Revoke keys when you change contractors: revocation takes effect within a minute at the latest.

#Data deletion

The procedure for deleting and correcting PII in an external CRM at the request of the data subject (the customer), including passing the request on to the recipient, is not described in the design.

#Open questions

• Deletion and correction of PII at a customer's request: the mechanism and the deadline (for the owner).
• The scope and parameters of GET /disclosures (technical; to be settled in OpenAPI and on the Authentication page).
• Whether the description applies equally to the EN and ID cells: ID is sold through a reseller partner, and the legal entity differs (for the owner).