Как мы усилили путь заявки,
не меняя саму форму.
Это реальный технический кейс STEKTO. Мы сравнили ранний обработчик заявок из версии v0.9.1 с текущим production-кодом и зафиксировали, что изменилось в надёжности и контроле ошибок.
Работало — но слишком многое оставалось «на удачу».
В раннем обработчике уже была полезная база: валидация, honeypot, Telegram и опциональное сохранение в Supabase. Но повторный клик, внешний запрос к API или слишком большой payload не имели отдельных защит.
До усиления
- Базовая валидация полей и honeypot.
- Отправка заявки в Telegram и опционально в Supabase.
- Нет обязательного consent в API.
- Нет same-origin проверки.
- Нет idempotency-защиты от повторного клика.
- Нет rate-limit и лимита размера тела запроса.
После усиления
- Consent обязателен до доставки заявки.
- Same-origin блокирует внешнюю отправку в API формы.
- Idempotency-key и fingerprint защищают от повторной доставки.
- Rate-limit: до 6 разных запросов на 10-минутное окно.
- Тело запроса ограничено 16 КБ.
- Заявка хранится в российском постоянном хранилище; Telegram получает только случайный внутренний ID без данных заявки.
- UTM, первая страница, реферер и текущая страница попадают в атрибуцию.
- Если обязательное российское хранилище недоступно, API отвечает 503; сбой Telegram не приводит к потере уже сохранённой заявки.
Повторная отправка не должна создавать две заявки.
Клиент может дважды нажать кнопку, браузер может повторить запрос, сеть — зависнуть. Поэтому фронтенд создаёт request ID, а API связывает его с fingerprint содержимого и хранит результат в коротком окне повторной отправки.
Создаёт idempotency key.
Проверяет fingerprint.
Выполняется один раз.
Получает тот же результат.
Не «потыкали руками», а закрепили поведением тестов.
Отдельный набор API-тестов запускает реальный обработчик в изолированной среде без production-секретов и проверяет успешные и аварийные ветки.
На контрольном запуске 22.09.2026 файл tests/api.test.mjs завершился результатом 19 tests · 19 pass · 0 fail.
Персональные данные заявки остаются в российском хранилище.
После юридического аудита persistence перенесён в постоянное хранилище приложения STEKTO в регионе Москва. Имя, контакт и свободный текст задачи больше не отправляются в Supabase и Telegram.
Telegram используется только как технический сигнал о новой заявке и получает случайный внутренний ID. Полные данные доступны только в закрытой админ-панели.
Мы проверяем не только «happy path».
При автоматизации важен не только сценарий «всё прошло успешно», но и дубль, сетевой сбой, недоступный сервис и повторная попытка. Именно эти ветки мы закладываем в критерии приёмки.