Приложение об интеграциях Evalife

Версия: 1.0

Дата вступления в силу: 15 июля 2026 года

Адрес публикации: https://evalife.ru/legal/integrations

1. Применение

Настоящее Приложение регулирует передачу и получение данных через CRM, webhooks, API, email, SMS, no-code-коннекторы и иные системы, подключенные к workspace Клиента.

2. Роли и граница контуров

2.1. Клиент выбирает интеграцию, получателя, набор полей, событие передачи и цель использования, поэтому поручает Evalife технически выполнить передачу.

2.2. Evalife контролирует формирование события, очередь, попытки доставки и защиту учетных данных в своей инфраструктуре.

2.3. Внешний контур начинается после принятия запроса endpoint, API или поставщиком доставки. Клиент отвечает за законность, конфигурацию, пользователей, хранение, удаление и безопасность в этом контуре.

2.4. Поставщик, выбранный Evalife для работы штатной функции, может быть субобработчиком Evalife. Сервис, учетную запись или endpoint которого самостоятельно выбирает Клиент, является получателем по указанию Клиента, если стороны не согласовали иное.

3. Условия подключения

Клиент подтверждает, что:

• вправе использовать внешний сервис и передавать ему данные;
• уведомил субъектов о получателях или категориях получателей;
• получил необходимые согласия;
• ограничил передаваемые поля минимально необходимым составом;
• настроил права, сроки хранения и удаление во внешнем сервисе;
• не передает запрещенные правилами форм данные;
• назначил ответственного за интеграцию.

4. Webhooks

4.1. Webhook отправляется только на разрешенный HTTPS endpoint и подписывается в соответствии с актуальной технической спецификацией.

4.2. Клиент проверяет подпись, timestamp, допустимое окно повторного воспроизведения и уникальный event ID до обработки payload.

4.3. Endpoint должен быть идемпотентным. Повторная доставка одного события не считается новым ответом формы.

4.4. Redirect на непроверенный адрес, отключение TLS-проверки и помещение секрета в URL запрещены.

5. API и токены

5.1. API-токен имеет workspace, владельца, scopes, дату создания, срок действия и статус.

5.2. Полное значение токена показывается только при создании, хранится Клиентом безопасно и не передается в форму, поддержку, исходный код или публичный репозиторий.

5.3. Клиент немедленно отзывает скомпрометированный токен. Evalife вправе отозвать токен при риске или нарушении.

5.4. Rate limits, scopes и форматы API определяются технической документацией https://evalife.ru/legal/rules-policies.

6. Яндекс OAuth, Метрика и Вебмастер

6.1. Подключение выполняется через Яндекс OAuth. Вход через Яндекс ID, чтение Метрики, изменение Метрики и доступ к Вебмастеру являются разными разрешениями и не включаются друг из друга автоматически.

6.2. Evalife показывает запрашиваемые scopes и действия до перехода в OAuth. Read-доступ используется для списка ресурсов, настроек и агрегированной статистики. Write-доступ может использоваться для создания и изменения счетчиков, целей, разрешенных настроек и индивидуальных доступов. Вебмастер может использоваться для добавления сайта, проверки прав и получения сведений об индексировании.

6.3. Клиент подтверждает полномочия пользователя на Яндекс-аккаунт, счетчики и сайты. Яндекс обрабатывает аккаунт и данные в собственном контуре по своим условиям.

6.4. По умолчанию Evalife не использует Logs API, не импортирует raw visits и не связывает visitor-level идентификаторы с ответами форм. Такие функции требуют отдельного режима и Legal/Privacy review.

6.5. OAuth token шифруется, не показывается в UI, не экспортируется, не записывается в логи и используется только scoped integration worker. Пользователь может отключить интеграцию в Evalife и отозвать grant в Яндекс ID.

6.6. Для сложной настройки Owner может отдельно разрешить индивидуальный доступ контролируемому Яндекс-логину Evalife к конкретному счетчику или сайту. Доступ имеет ticket, роль, действия, срок, audit-log и обязательный отзыв. Представительский доступ ко всему аккаунту запрещен по умолчанию. Evalife не запрашивает пароль, session cookie, одноразовый или recovery-код Клиента.

7. CRM

7.1. Клиент определяет соответствие полей формы полям CRM, правила создания и обновления записей, дедупликацию и ответственных пользователей.

7.2. Evalife не отвечает за автоматизации, рассылки, звонки, скоринг и решения, запущенные CRM после приема данных.

8. Email и SMS

8.1. Технические уведомления направляются в связи с действием пользователя или исполнением договора.

8.2. Рекламные сообщения допускаются только при предварительном согласии, возможности отказа и проверке suppression status.

8.3. Клиент отвечает за отправителя, шаблон, аудиторию, частоту, основание и обязательные сведения в сообщении. Правила Evalife: https://evalife.ru/legal/mailing-rules.

8.4. Статус «принято поставщиком» не гарантирует доставку на устройство адресата.

9. Consent context

При передаче, когда это необходимо для цели, Evalife может включать:

• form_id и submission_id;
• идентификатор и версию текста согласия;
• дату и время действия;
• выбранные каналы;
• источник и URL формы;
• технический статус согласия или отказа.
• идентификатор и статус contact verification;
• suppression status на момент постановки и отправки.

Клиент не вправе изменять доказательство так, чтобы создать ложное впечатление о согласии.

Автоматическая contact-bearing передача запрещена для pending, rejected, expired, disputed и active suppression. Pending-заявка остается доступной Клиенту в защищенном кабинете. Это не я отменяет queued/retry jobs и создает blocking/revocation tasks для прежних получателей.

10. Delivery log

10.1. Evalife фиксирует event ID, workspace, тип интеграции, endpoint в маскированном виде, время попыток, HTTP/status code, результат, число повторов и correlation ID.

10.2. Тела ответов и payload не записываются полностью, если это не требуется для кратковременной защищенной диагностики.

10.3. Delivery log хранится 12 месяцев после попытки доставки.

11. Ошибки и повторные попытки

11.1. Evalife применяет ограниченные повторные попытки с задержкой. Некорректные credentials, постоянный отказ endpoint или нарушение правил могут привести к отключению интеграции.

11.2. Клиент получает доступный статус ошибки и самостоятельно исправляет внешний сервис. Evalife не обязана бесконечно хранить событие или обеспечивать ручную доставку.

12. Безопасность

12.1. Секреты хранятся в HashiCorp Vault и Kubernetes External Secrets с раздельными сервисными доступами, шифруются, маскируются и доступны ограниченным сервисным ролям.

12.2. Evalife применяет защиту от SSRF, ограничение адресов и портов, таймауты, лимиты размера и иные меры, соответствующие риску.

12.3. Клиент сообщает о компрометации на security@evalife.ru.

13. Отключение и удаление

13.1. При отключении Evalife прекращает новые передачи и удаляет или отзывает относящиеся к интеграции секреты по регламенту.

13.2. Отключение не удаляет ранее переданные данные во внешнем сервисе. Это выполняет Клиент.

13.3. Evalife вправе немедленно остановить интеграцию при утечке, атаке, незаконной передаче или угрозе инфраструктуре.

14. Ответственность

Evalife отвечает за свой компонент и выполнение документированного указания. Клиент отвечает за выбор внешнего сервиса, правовые основания и внешний контур. Каждая сторона отвечает за собственные учетные данные и действия своих пользователей.

15. Связанные документы

• DPA: https://evalife.ru/legal/dpa;
• правила форм: https://evalife.ru/legal/form-rules;
• меры защиты: https://evalife.ru/legal/security-measures;
• SLA: https://evalife.ru/legal/sla;
• список поставщиков: https://evalife.ru/legal/subprocessors.