← Все кейсыВнутренний кейс · STEKTO · 2026

Как мы усилили путь заявки,
не меняя саму форму.

Это реальный технический кейс STEKTO. Мы сравнили ранний обработчик заявок из версии v0.9.1 с текущим production-кодом и зафиксировали, что изменилось в надёжности и контроле ошибок.

18 / 18API-тестов проходят
16 КБлимит тела запроса
6 / 10 минrate-limit разных заявок
Исходная точка

Работало — но слишком многое оставалось «на удачу».

В раннем обработчике уже была полезная база: валидация, honeypot, Telegram и опциональное сохранение в Supabase. Но повторный клик, внешний запрос к API или слишком большой payload не имели отдельных защит.

v0.9.1

До усиления

  • Базовая валидация полей и honeypot.
  • Отправка заявки в Telegram и опционально в Supabase.
  • Нет обязательного consent в API.
  • Нет same-origin проверки.
  • Нет idempotency-защиты от повторного клика.
  • Нет rate-limit и лимита размера тела запроса.
Текущая версия

После усиления

  • Consent обязателен до доставки заявки.
  • Same-origin блокирует внешнюю отправку в API формы.
  • Idempotency-key и fingerprint защищают от повторной доставки.
  • Rate-limit: до 6 разных запросов на 10-минутное окно.
  • Тело запроса ограничено 16 КБ.
  • Telegram-сообщение ограничено по длине и отправляется как plain text.
  • UTM, первая страница, реферер и текущая страница попадают в атрибуцию.
  • При недоступности всех каналов API отвечает 503, а не притворяется успешным.
Ключевой сценарий

Повторная отправка не должна создавать две заявки.

Клиент может дважды нажать кнопку, браузер может повторить запрос, сеть — зависнуть. Поэтому фронтенд создаёт request ID, а API связывает его с fingerprint содержимого и хранит результат в коротком окне повторной отправки.

01Форма

Создаёт idempotency key.

02API

Проверяет fingerprint.

03Доставка

Выполняется один раз.

04Повтор

Получает тот же результат.

Как проверили

Не «потыкали руками», а закрепили поведением тестов.

Отдельный набор API-тестов запускает реальный обработчик в изолированной среде без production-секретов и проверяет успешные и аварийные ветки.

01Consent / origin / honeypotPASS
02Oversized JSONPASS
03Telegram + attributionPASS
04Повторная отправкаPASS
05Retry после сбояPASS
06Rate-limitPASS
07503 без канала доставкиPASS
08Health без утечки credentialsPASS

На контрольном запуске 22.09.2026 файл tests/api.test.mjs завершился результатом 18 tests · 18 pass · 0 fail.

Production-проверка

Telegram и резервная база подтверждены одним реальным запросом.

22.09.2026 через публичный production API отправили синтетическую заявку TEST ONLY. Сервер ответил HTTP 201 с persisted:true и notified:true: Supabase сохранил строку, Telegram API подтвердил уведомление.

После проверки строку нашли в базе по requestId и удалили. Таблица работает с RLS: публичному ключу разрешена только вставка по политике, чтение строк не возвращает данные.

Что это показывает клиенту

Мы проверяем не только «happy path».

При автоматизации важен не только сценарий «всё прошло успешно», но и дубль, сетевой сбой, недоступный сервис и повторная попытка. Именно эти ветки мы закладываем в критерии приёмки.