Сравнение
Проверка email в реальном времени или списком
Проверяйте новый адрес, пока человек заполняет форму, или сохраненные адреса в своем процессе. API общий; различаются доступное время и решение, которое нужно принять.
| Что вы хотите узнать | В реальном времени | Списком |
|---|---|---|
| Когда проверять | При регистрации, заказе или отправке заявки | При обработке адресов, уже сохраненных в списке или базе |
| Кто ждет результат | Человек перед формой | Ваш процесс или его оператор, а не человек в форме |
| Если ответ pending | Опрос до предела ожидания формы, затем запасное правило | Сохранение идентификатора и получение результата в пределах срока задачи |
| Свидетельства и результаты | Четыре итоговых статуса, action, checks и reason codes | Те же поля; свидетельства зависят от глубины и времени проверки |
| Как вызывается Emvero | Один серверный запрос для отправленного адреса | Один запрос на адрес в вашем собственном цикле |
| Что делать с unknown | При необходимости разрешить регистрацию с подтверждением | Отделить невыясненные строки для разбора или повторной проверки |
Выбирайте момент по задаче
Используйте проверку в реальном времени, когда человек еще может исправить адрес при регистрации, заказе или отправке заявки. Форме нужны предел ожидания и понятный следующий шаг. Явная ошибка формата или приема почты может быть поводом для исправления; неопределенность не должна превращаться в ложную ошибку.
Используйте массовую проверку для сохраненных адресов. Ваш скрипт или приложение читает строку, вызывает API и записывает полученные поля рядом с ней. Emvero получает один адрес на запрос. Вы управляете входными и выходными данными; загрузки CSV в сервис и отдельного пакетного эндпоинта нет.
Долгое ожидание не гарантирует однозначный ответ
Оба процесса могут получить pending. Подождите retry_after_ms, затем вызовите GET /v1/verifications/{id} с тем же ключом. Callback нет. Форма задает свой предел ожидания, а фоновая задача может сохранить идентификатор и получить результат позже.
Фоновому процессу тоже нужны подходящий темп, ограничение повторов и срок завершения. Принимающий сервер может продолжать скрывать сведения о получателе, поэтому даже законченная проверка может дать unknown. Храните отдельно ошибки сервиса, выполняющиеся проверки и итоговые результаты. Страница API объясняет этот контракт.
Глубину проверки выбирайте отдельно
В обоих процессах доступны full и domain из одного баланса кредитов. Полная проверка может собрать свидетельства о получателе. Проверка домена заканчивается до SMTP-пробы и не устанавливает существование отдельного ящика. Этот выбор разобран в сравнении полной проверки и проверки домена.
Словарь результатов общий, но доступные свидетельства меняются с глубиной, временем и поведением принимающего сервера. Ни один процесс не гарантирует доставку. Читайте действие и reason codes, а не превращайте статус в неизменную инструкцию.
При длительном хранении адресов используйте оба процесса
Проверка при вводе помогает исправить ошибку сразу. Более поздняя проверка может найти изменения в ящике или домене до использования сохраненного контакта. Ни одна из них не устанавливает согласие на маркетинг или интерес к письмам.
Руководство по форме регистрации объясняет исправления и подтверждение при создании аккаунта. Руководство по очистке списка показывает, как отделять и разбирать невыясненные строки. Правила могут различаться даже при одинаковом статусе API.
Где это видно в результате
Коды причин из закрытого словаря ответа API. Это ровно те строки, против которых интеграция пишет if.
SMTP_GREYLISTED | Временная отсрочка SMTP; более поздняя проверка может помочь, но не гарантирует однозначного результата. |
SMTP_CONNECT_TIMEOUT | Почтовый сервер не ответил вовремя |
Посмотрите результат проверки.
В примере показаны статус, рекомендуемое действие и свидетельства проверки. Войдите в аккаунт, чтобы проверить свой адрес.