Открытая регистрация привлекает не тех пользователей
Вам нужны только одобренные пользователи, но открытая регистрация пускает злоупотребителей и нерелевантные аккаунты. Ручные проверки отнимают время и всё равно пропускают плохие регистрации.
API белого списка для доверенной регистрации и рассылок
Одобряйте, кто может регистрироваться или получать письма — по конкретному адресу или целому домену. Управляйте доступом одним полем `block`, без дублирования логики белого списка в сервисах.
Карта не нужна. Можно протестировать на бесплатных кредитах.
1 поле
для разрешения или запрета (`block`)
2 типа правил
точный email и целый домен
Вкл / Выкл
режим белого списка при смене политики
В реальном времени
проверки политики в ответе верификации
Белый список убирает дорогие ошибки политики
Оставляйте в потоках только одобренных пользователей и получателей, централизуя решения по политике в одном ответе API.
Логика allow-list дублируется в разных сервисах
Регистрация, CRM и рассылки требуют одной политики, но каждый сервис реализует её по-своему и со временем расходится.
Вы платите за отправки не той аудитории
Когда письма должны получать только определённые клиенты, широкие списки съедают бюджет кампаний и размывают метрики получателями вне вашей политики.
Сценарий белого списка
Как работает белый список
Один раз определите, кому можно, затем принимайте решения по политике из одного поля в каждом результате проверки.
01→
Добавьте правила белого списка
Добавьте точные адреса вроде [email protected] или домены вроде company.com, чтобы определить, кому разрешено.
02→
Включайте режим белого списка по необходимости
Включайте белый список, когда должны проходить только перечисленные email и домены. Выключайте, когда строгий allow-only не нужен.
03✓
Проверьте и решите по полю block
Используйте поле `block` в ответе API. `block: true` — запретить, `block: false` — разрешить.
Пример ответа API верификации
GET /v1/[email protected]\nX-API-Key: your-api-key\n\n{\n "valid": true,\n "block": false,\n "domain": "customer.org"\n}Что можно внести в белый список
Точный email
Разрешить один конкретный адрес, когда должны проходить только выбранные пользователи.
Домен
Разрешить все ящики на одобренных доменах, например partner.com или customer.org.
Команды, которые используют API белого списка в продакшене
Реальные команды защищают онбординг белым списком, сужают таргетинг рассылок и не держат логику политики в коде приложения.
DR
Даниил Рид
Основатель, B2B SaaS
“Мы включили белый список для enterprise-проб и сразу перестали получать случайные регистрации. Продажи общаются только с теми аккаунтами, которые мы реально целим.”
SM
София Мартинес
Руководитель lifecycle-маркетинга
“Для кампаний только для партнёров мы вносим одобренные домены в белый список и не шлём не той аудитории. Меньше лишних отправок и лучше метрики.”
ML
Маркус Ли
Product manager, маркетплейс
“Раньше у нас была своя allow-логика в нескольких сервисах. Теперь каждый поток читает одно и то же поле `block` и ведёт себя одинаково.”
Частые вопросы об API белого списка
Какое поле использовать для разрешения или запрета?
Поле `block` в ответе верификации. Если `block` истинно — запретить действие. Если ложно — разрешить.
Можно ли вносить в белый список и точные email, и целые домены?
Да. Добавляйте точные адреса для точного доступа или домены вроде `company.com`, чтобы разрешить все ящики на этом домене.
Можно ли включать и выключать политику белого списка?
Да. Режим белого списка можно включать и отключать, чтобы строгое поведение «только из списка» действовало только когда нужно.
Это убирает необходимость в собственной allow-list логике?
Да. Правила белого списка задаются один раз, а решение читается из `block` в ответе API вместо дублирования сопоставления в бэкендах.
Что если адрес и в белом, и в чёрном списке?
Приоритет у чёрного списка. Если сработало правило чёрного списка, `block` остаётся истинным, даже если адрес или домен есть в белом списке.