Данные и сроки хранения¶
Страница для интегратора и для того, кто отвечает за персональные данные: что хаб хранит, как долго и что с этим можно сделать.
Время¶
Все моменты времени в API — UTC, ISO-8601 (2026-09-10T04:12:33.481Z).
Локальных зон в контракте нет ни в одном поле: часовой пояс отправителя,
получателя и оператора — три разных пояса, и любой из них в ответе означал бы
вопрос «чей».
Что хранится¶
| Данные | Где | Что именно |
|---|---|---|
| Номер получателя | оперативная база | в открытом виде — он нужен для отправки и разбора обращений; первый год, дальше убирается (Сроки) |
| Хеш номера | оперативная база, аналитика | SHA-256; по нему идут анти-флуд, отписка и отчёты. Остаётся и после того, как номер убран, но не навсегда: в аналитике у строк с хешем свой срок (Сроки) |
| Текст сообщения | оперативная база | кроме одноразовых кодов — см. ниже; первый год, дальше убирается вместе с номером |
| Переменные шаблона | оперативная база | у одноразовых кодов маскируются; убираются вместе с текстом |
| Сырые ответы оператора | аналитика | тело как пришло, вместе с номером |
| Сохранённые ответы идемпотентности | оперативная база | объект сообщения целиком, сутки |
Текст одноразового кода не хранится вообще. Он и есть секрет: хранение превратило бы таблицу сообщений в таблицу действующих кодов. В эфир текст уходит через очередь, в базе остаются шаблон и маска переменных.
В логах номера нет — он маскируется до вида +7901***3344, и это
проверяется сквозным прогоном: после отправки логи всех семи сервисов
просматриваются на полный номер и на код.
В разобранной аналитике номера нет — только хеш (история переходов статуса); в журнале событий номера нет вовсе. Хеш не анонимизация: пространство номеров мало, и перебор российской нумерации занимает минуты. Это способ не хранить номер открытым, а не защита от восстановления.
Исключение — сырые тела, 90 дней. Ответы и отчёты оператора и входящие сообщения сохраняются «как пришли», вместе с номером, а у входящих — и с текстом: разбор мог оказаться неполным, а второго шанса получить тело нет. Через 90 дней их удаляет сама СУБД; по запросу субъекта персональных данных они чистятся раньше вместе с остальным.
Сроки¶
Срок хранения сообщений — две ступени: через год у сообщения пропадают
номер получателя и текст, через три года сообщение исчезает целиком. Отсчёт —
от времени приёма сообщения хабом (created_at).
| Данные | Срок | Чем обеспечен |
|---|---|---|
| Номер получателя и текст сообщения в оперативной базе | 1 год | по сроку убираются из закрытых сообщений и из входящих; сама запись остаётся |
| Обезличенная запись: хеш номера, статусы и их история, времена, попытки, части и цена | 3 года с приёма сообщения, затем удаляется | по сроку удаляются сообщения с историей статусов, события журнала, журнал попыток доставки вебхуков и входящие |
| Сырые ответы оператора, входящие, запросы к оператору — в аналитике, с номером и текстом входящих | 90 дней | TTL в схеме аналитики — удаляет сама СУБД |
| Детализация аналитики: журнал событий (без номера) и история переходов статуса (по хешу номера) | 13 месяцев от времени события или перехода | TTL в схеме аналитики — удаляет сама СУБД |
| Предагрегаты аналитики: суточные счётчики по тенанту, режиму, классу, статусу и причине | бессрочно | срока нет: человека в строке нет вовсе |
| Ключи идемпотентности | 24 часа | периодическая уборка в маршрутизаторе |
| Списания (учёт расходов) | бессрочно, отдельно от сообщений | по сроку хранения сообщений не удаляются; бухгалтерский срок в любом случае длиннее |
| Отписки | бессрочно | удалить отписку — значит возобновить отправку |
Ступени две, потому что вопроса тоже два. Номер и текст — персональные данные, и держать их дольше, чем нужно для цели, нельзя; цель эта — отправка и разбор свежего обращения — исчерпывается гораздо раньше трёх лет. А доказать сам факт отправки может потребоваться в пределах срока исковой давности, и для этого номер не нужен: хватает хеша, статусов и времён.
Списания живут дольше сообщений, и это не расхождение. У финансовых записей
свой, бухгалтерский срок и своё основание — отчётность, а не спор об отправке.
Персональных данных в них нет: сообщение, тенант, части, цена, основание.
Отсюда следствие, о котором стоит знать заранее: сводка /v1/stats за период
старше трёх лет пуста, а деньги за тот же период в учёте есть.
В аналитике сроки разведены по тому же признаку — есть в строке человек или нет. Детализация — журнал событий и история переходов — идёт по хешу номера, а хеш мы не считаем анонимизацией (см. выше), поэтому держать её бессрочно незачем: 13 месяцев. Тринадцать, а не двенадцать, потому что детализация нужна для сравнения месяца с тем же месяцем год назад, и на двенадцати прошлогодний месяц истекал бы прямо во время сравнения. Предагрегаты и списания хранятся бессрочно: в их строках нет ни номера, ни хеша — только тенант, период, класс, статус, причина и числа, — места они занимают копейки, а отчётность за любой год остаётся и после того, как детализация за него удалена.
Что это значит для интегратора¶
Сообщению больше года. GET /v1/messages/{id} по-прежнему отвечает 200,
но поле to пустое и текста нет. Всё остальное на месте: идентификатор, статус,
вся история статусов, времена, число попыток, части и цена, ссылки на пакет,
шаблон и отправителя. Листинги показывают те же поля без номера и текста. Сводка
/v1/stats не меняется: она считается по сообщениям, а их не убыло. Журнал
событий работает как раньше — в телах событий не будет номера и текста.
Сообщению больше трёх лет. GET /v1/messages/{id} — 404 not_found;
листинги и сводка /v1/stats за такой период — пустые.
- Курсор журнала
GET /v1/events?starting_after=evt_…, указывающий на событие старше трёх лет, —404 not_found, а не молчаливое чтение с начала журнала. Продолжать — по времени:GET /v1/events?created_after=<created_at последнего обработанного события минус 1 мс>и отбрасывать уже обработанные поevent.id. Фильтр строгий (created_at >), а у нескольких событий одна и та же миллисекунда — обычное дело: без этого отступа события из той же миллисекунды, что и последнее обработанное, будут потеряны. События, ещё не доставленные вебхуком, по сроку не удаляются. - Повтор с тем же
client_refраспознаётся как повтор, пока исходное сообщение хранится; через три года тот жеclient_refсоздаст новое сообщение. Обезличивание на это не влияет:client_refне трогается.
Независимо от сроков данные убираются по обращению субъекта — см. ниже.
Обращение субъекта персональных данных¶
По обращению номер убирается из всех хранилищ: из сообщений вместе с текстами и переменными, из входящих, из сохранённых ответов идемпотентности, из сырых тел аналитики. Обращение принимает оператор хаба, а не API.
Отписка при этом сохраняется: из её строки убирается номер, остаётся хеш. Удалить строку значило бы возобновить отправку тому, кто просил её прекратить, — в ответ на его же обращение.
Обезличивание необратимо. Восстановить убранное нечем: резервная копия старше обращения помогала бы только нарушая само обращение.
Кто оператор персональных данных¶
Хаб — внутренний сервис группы компаний и обрабатывает данные по поручению тенанта: номера абонентов принадлежат тому, кто отправляет им сообщения. Конкретное юридическое оформление (кто оператор, кто обработчик, чем это закреплено) — вопрос договора между тенантом и группой, а не этой страницы.