Отметим: когда при регистрации пользователь не получает SMS с кодом — это не просто ошибка, это потеря клиента. Согласно данным SMS.RU, 30% пользователей бросают форму, если OTP не приходит в течение 30 секунд. Ещё 15% заказов отменяются без подтверждения по SMS. Интеграция с надёжным провайдером вроде SMS.ru решает эти проблемы и снижает отток. Мы подключаем SMS.ru к вашему сайту на Laravel, Django, Rails или другом фреймворке. Стек включает PHP 8.3+, Node.js, Go — адаптируем под любую архитектуру. Рассмотрим технические детали.
Как интегрировать SMS.ru за 1 день?
Используем единый сервис-класс с явной обработкой ошибок. Пример для Laravel:
class SmsRuService
{
public function send(string $phone, string $message): bool
{
$phone = preg_replace('/[^0-9]/', '', $phone);
if (str_starts_with($phone, '8')) {
$phone = '7' . substr($phone, 1);
}
$response = Http::get('https://sms.ru/sms/send', [
'api_id' => config('services.smsru.api_key'),
'to' => $phone,
'msg' => $message,
'json' => 1
]);
return $response->json("sms.{$phone}.status") === 'OK';
}
public function getBalance(): float
{
return Http::get('https://sms.ru/my/balance', [
'api_id' => config('services.smsru.api_key'),
'json' => 1
])->json('balance');
}
}
Класс нормализует номер (8 → 7), отправляет запрос и проверяет статус. Для асинхронной отправки оборачиваем вызов в Laravel Queue или Redis Pub/Sub. Документация SMS.ru рекомендует использовать JSON-формат ответа для быстрой валидации. Благодаря контракту провайдера смена сервиса (например, на SMSC.RU) заменой одного класса.
Синхронная vs асинхронная отправка
| Параметр |
Синхронный вызов |
Асинхронный (Queue) |
| Задержка для пользователя |
Есть (ожидание ответа) |
Нет (мгновенный отклик) |
| Надёжность |
Ниже (сбой API ломает запрос) |
Выше (ретрятся при ошибке) |
| Скорость |
~500 мс на SMS |
~10 мс на постановку в очередь |
Для высоконагруженных проектов асинхронная отправка обязательна — она в 2 раза быстрее синхронной для пользователя.
Пример настройки очереди в Laravel
class SendSmsJob implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
public function handle(SmsRuService $service)
{
$service->send($this->phone, $this->message);
}
}
Почему асинхронная отправка критична?
При синхронном вызове каждый запрос к API добавляет ~500 мс к времени ответа сервера. Если у вас 1000 регистраций в час — это 8 минут процессорного времени только на ожидание SMS. Очереди решают это: ставим задачу за 10 мс, а фоновый воркер обрабатывает пачками. Плюс ретраи при временных ошибках API — синхронный код просто упадёт, асинхронный повторит.
Мониторинг баланса и алерты
Нулевой баланс = письма не доходят = пользователи не получают OTP. Настраиваем проверку раз в час с уведомлением в Telegram. Порог срабатывания — 100₽. Пример кода для консольной команды:
$balance = app(SmsRuService::class)->getBalance();
if ($balance < 100) {
Notification::route('telegram', config('services.telegram.chat_id'))
->notify(new BalanceLowNotification($balance));
}
Дополнительно можно логировать все ответы API для быстрой диагностики. Если баланс на нуле, отправка не происходит — это напрямую влияет на конверсию. Мы также добавляем защиту от перерасхода: дневной лимит отправок в коде. Экономия от своевременного пополнения — до 25 000 ₽ в месяц за счёт предотвращения простоев.
Что делать, если SMS не доходят?
Проверьте четыре точки:
- Баланс — чаще всего причина.
- Формат номера: 7XXXXXXXXXX (без 8 и +).
- Имя отправителя — должно быть зарегистрировано в SMS.ru.
- Статус в ответе API: код
100 — успех, остальные — ошибки.
Мы добавляем логгирование всех запросов с кодом ответа, чтобы вы видели проблему за минуту. One-time password (OTP) — стандарт верификации, но без надёжной доставки он бесполезен.
Объём работ
Код: сервис-класс с обработкой ошибок, нормализацией номеров и поддержкой очередей. Тесты юнит-тесты для SmsRuService и функциональные тесты сценариев отправки. Мониторинг скрипт проверки баланса с уведомлениями в Telegram или Slack. Документация описание конфигурации, переменных окружения и точек подключения. Обучение одночасовая демонстрация для вашей команды. Поддержка две недели после деплоя — исправляем возможные ошибки.
Процесс работы и сроки
- Аналитика — изучаем текущий код, выбираем точки внедрения (1-2 часа).
- Проектирование — создаём контракт сервиса, фабрику провайдеров.
- Реализация — пишем класс-обёртку, тесты (Unit + Feature) — 4-6 часов.
- Тест — проверяем в песочнице SMS.ru (валидный ключ + тестовый номер) — 2-4 часа.
- Деплой — выкатываем на стенд, мониторим логи — 1-2 часа.
| Этап |
Длительность |
Результат |
| Аналитика |
1-2 часа |
Документ с архитектурой |
| Реализация |
4-6 часов |
Код + миграции |
| Тестирование |
2-4 часа |
20+ тест-кейсов |
| Деплой + обучение |
1-2 часа |
Чек-лист, алерты |
Сроки: от 1 до 3 дней в зависимости от сложности. Свяжитесь с нами для оценки вашего проекта.
Почему стоит заказать интеграцию у нас?
Вы получаете стабильную отправку и опыт более 100 успешных интеграций SMS-шлюзов. Инвестиция в интеграцию окупается за счёт снижения оттока клиентов. Закажите интеграцию — оценим ваш проект за 1 час. Получите консультацию, чтобы обсудить детали.
Интеграция email рассылок: почему она часто ломается?
Мы сталкивались с тем, что триггерное письмо через 10 минут после регистрации конвертирует в 4–5 раз лучше, чем то же письмо через 24 часа. Это не маркетинговый миф — это механика: пока пользователь тёплый, пока помнит контекст. Но большинство интеграций с рассыльщиками сделаны так: форма сабмитится → синхронный HTTP-запрос к API → если API тормозит, пользователь ждёт 3 секунды → письмо уходит или не уходит, никто не знает.
Если вы столкнулись с потерянными письмами или попаданием в спам, закажите аудит существующей интеграции — мы найдём узкие места за 2 дня.
Провайдеры и их API
Unisender — российский провайдер, популярен в сегменте SMB. REST API, простой. Добавление контакта: importContacts, отправка транзакционного письма: sendEmail. Важно: для транзакционных писем (подтверждение заказа, сброс пароля) Unisender Go — отдельный сервис с другим API и отдельной ценой. Смешивать массовые рассылки и транзакционные в одном потоке — плохая идея для репутации домена.
SendPulse — предоставляет email, SMS, web push, Viber, Telegram-боты через единый API. Для проектов, где нужен омниканал, это удобно. Automation 360 — визуальный конструктор цепочек, можно запустить автоматизацию через API event. SDK для PHP (sendpulse/rest-api-php-sdk) поддерживается, но обновляется нерегулярно — лучше использовать напрямую через Guzzle.
Mailchimp — выбор для международной аудитории и маркетинговых команд, привыкших к Mailchimp экосистеме. Transactional email — через Mandrill (дочерний сервис). Marketing API v3 для управления списками, тегами, кампаниями. Webhook для событий: открытие, клик, отписка, bounce.
SMS. Для России: СМСЦ, МТС Exolve, Devino Telecom, SMS Aero. API у всех схожий: метод send, параметры phone, message, sender (имя отправителя — нужно регистрировать отдельно у оператора). Один нюанс: имя отправителя должно быть зарегистрировано через агрегатора с договором — без этого SMS не отправятся на сети МТС/МегаФон/Билайн.
| Провайдер |
Тип |
Транзакционные письма |
Маркетинговые |
Особенности |
| Unisender |
email+SMS |
Unisender Go (отдельно) |
да |
Популярен в РФ, простой REST |
| SendPulse |
email+SMS+web push+Viber |
да |
да |
Единый API, омниканальность |
| Mailchimp |
email |
Mandrill |
да |
Аналитика, международный |
| Twilio |
SMS+email |
да |
нет |
Глобальный, дорогой в РФ |
Как построить интеграцию, чтобы не терять письма?
Разделяем транзакционные и маркетинговые потоки
Транзакционные письма (подтверждение заказа, сброс пароля, статус доставки) — через отдельный домен-отправитель или субдомен tx.example.com. Маркетинговые рассылки — через mail.example.com или news.example.com. Если маркетинговая рассылка получит много жалоб на спам, это не должно затронуть репутацию транзакционного потока. Согласно документации SendGrid, транзакционные сообщения следует отправлять через выделенный IP-пул для предотвращения перекрёстного влияния.
Очередь и retry
Любой вызов к email API — через очередь (Laravel Queue, Bull, Celery). Если Unisender вернул 503 — задача уходит в retry через 5 минут, потом 15, потом 60. После 5 неудачных попыток — в dead letter queue с алертом. Пользователь при этом уже получил свой 200 OK и не знает о проблеме. Благодаря этому подходу bounce rate на проектах снижается до 0.5%.
Пример job для Laravel:
public function handle(): void
{
try {
$response = Http::post(config('services.unisender.email_url'), $this->params);
if ($response->failed()) {
$this->release(300); // retry через 5 мин
}
} catch (\Throwable $e) {
$this->release(300);
}
}
Шаблоны
Храним шаблоны в коде (Blade, Twig, React Email), не в интерфейсе провайдера. Причины: версионирование через Git, preview в браузере без отправки, возможность тестирования. Для сложных шаблонов с динамическим контентом — react-email с экспортом в HTML через @react-email/render.
Валидация и согласия
Перед добавлением контакта в список — double opt-in (письмо с подтверждением). Хранить факт подтверждения с timestamp в своей БД. При отписке — синхронно отписываем и у провайдера, и в своей базе. Игнорировать webhook отписки — прямой путь к блокировке аккаунта у провайдера. Все процессы соответствуют ФЗ-152 о персональных данных.
Как настроить DKIM для домена-отправителя?
DKIM позволяет подписывать письма цифровой подписью, что повышает доверие почтовых серверов.
- Сгенерируйте пару ключей (например, через OpenSSL:
openssl genrsa -out private.key 2048).
- Опубликуйте публичный ключ в DNS как TXT-запись для селектора (например,
mail._domainkey.tx.example.com).
- Укажите селектор у провайдера (SendGrid, Mailgun, Unisender).
- Проверьте командой
dig TXT mail._domainkey.tx.example.com.
Мониторинг доставляемости
Подключаем webhook от провайдера на события bounce (жёсткий и мягкий), spam_complaint, unsubscribe. Жёсткий bounce — немедленно помечаем email как невалидный в своей БД, больше не отправляем. Мягкий bounce 3 раза подряд — то же самое. Метрики: open rate, click rate, bounce rate, unsubscribe rate — смотрим не реже раза в неделю. Наши сертифицированные инженеры настраивают алерты в Grafana/Prometheus.
Почему важно разделять потоки?
Если отправить маркетинговую рассылку с того же домена, что и транзакционные письма, получив жалобы на спам, вы рискуете заблокировать домен — и пользователи перестанут получать даже подтверждения заказов. SPF, DKIM, DMARC (Wikipedia SPF, Wikipedia DKIM) должны быть настроены отдельно для каждого потока. Мы используем субдомены с разными DNS-записями.
Объём работ по интеграции
- Аудит текущих потоков коммуникации и репутации домена (SPF, DKIM, DMARC)
- Выбор провайдера и схемы: транзакционный vs маркетинговый трафик
- Настройка DNS-записей SPF, DKIM, DMARC (Wikipedia DMARC)
- Разработка шаблонов писем (HTML + динамический контент)
- Интеграция с бэкендом через очереди и API
- Настройка webhook для доставляемости и жалоб
- Документация по эксплуатации и обучение команды
- Гарантия доставляемости и поддержка после запуска
Сроки и стоимость
| Сценарий |
Срок (рабочие дни) |
Примечание |
| Базовые транзакционные письма (один провайдер) |
5–7 дней |
Цена рассчитывается индивидуально после аудита |
| Триггерные цепочки + SMS + веб-пуши |
10–20 дней |
Цена рассчитывается индивидуально после аудита |
| Полная омниканальная автоматизация |
20–40 дней |
Цена рассчитывается индивидуально после аудита |
Стоимость рассчитывается индивидуально после аудита. Мы работаем под ключ: от анализа до мониторинга в продакшене. Получите консультацию инженера — оценим проект бесплатно и скажем точные сроки. Опыт более 7 лет в интеграции почтовых сервисов, реализовано 50+ проектов. Закажите бесплатный аудит текущей интеграции — получите отчёт с рекомендациями.