Интеграция Telegram бота с Google Sheets и Notion

Иногда утро выглядит так: ты открываешь ноутбук с мыслью «сейчас быстренько», а в Telegram уже стучится десяток пользователей с заявками. Они хотят ответов, а ты хочешь, чтобы все данные не растекались по чатам, а шли в аккуратные таблицы и понятные базы. Через полчаса понимаешь, что копировать руками — путь в никуда, и вместо кофе наливаешь себе небольшой интеграционный марафон. Телеграм‑бот должен уметь записывать строки в Google Sheets и создавать страницы в Notion, иначе это всё развалится при первом же всплеске внимания.

Я прошёл это несколько раз — сначала на маленьких MVP для своих команд, потом на проде, где пользователи приходят волнами. В Ticky AI нам пришлось сводить ответы из бота и пользовательские заметки к одной логике, чтобы заявки не терялись. В итоге раскладывается ясная картина: архитектура, доступы, модель данных, ограничения и наблюдаемость. Если эти пять вещей продумать заранее, интеграция Telegram бота с Google Sheets и Notion перестаёт быть лотереей и становится системной штукой.

Попробуйте бот, который помогает собирать и структурировать данные: t.me/TickyAI_bot.

Что именно мы автоматизируем и зачем

Когда говорят «интеграция Telegram бота с Google Sheets и Notion», обычно имеется в виду связка из трёх простых действий. Пользователь пишет боту, бот превращает сообщение в структуру данных, а дальше эта структура кладётся в таблицу и создаёт страницу в базе. Таблица удобна для быстрых фильтров, сводных отчётов, импорта в аналитику; Notion — для CRM‑карточек, контента, контекстных связей и совместной работы. Полезно сразу решить, что хранится где: сырые события и агрегаты в Sheets, сущности с комментариями и чек‑листами в Notion. Так не будет дублей, и каждое хранилище отвечает за свою роль.

Поверх этого добавляются мелочи, которые легко пропустить. Например, связываем записи: message_id из Telegram — это ваш якорь, на основе которого появятся row_id в таблице и page_id в Notion. Если связь не сохранять, потом сложно понять, какой лид к какой странице относится. Ещё вопрос — когда писать в оба хранилища: синхронно, чтобы пользователь сразу получил «Готово», или асинхронно, чтобы не попасть в сетевые задержки. Ответ зависит от архитектуры и терпимости к задержкам в 1–10 секунд.

Архитектуры: прямые вызовы против промежуточного слоя

Есть два проверенных подхода. Первый — прямые вызовы из бота в Google Sheets API и Notion API. Второй — бот получает сообщение, кладёт событие в очередь, а обработчик уже общается с внешними API. По сути, выбор между скоростью старта и запасом прочности.

Прямые вызовы API

Это путь для быстрого MVP. Бот разобрал сообщение, сформировал полезную нагрузку и сразу сделал append в Sheets и create page в Notion. Плюсы очевидны: меньше кода, меньше движущихся частей и прозрачный отладочный цикл. Если пользователь ошибся в телефоне — можно на месте вернуть уточняющий вопрос. Минусы проявляются на росте: Telegram, Google и Notion имеют лимиты, а ошибки сети всегда случаются не вовремя. Придётся прямо в боте реализовать ретраи, идемпотентность и разруливать случаи, когда таблица внезапно переименована, а у Notion изменились свойства базы.

Промежуточный слой: вебхук, очередь и воркер

Когда пользователей становится много, выигрывает архитектура с буферизацией. Бот принимает вебхук, валидирует минимально необходимое и пишет событие в очередь — от RabbitMQ до SQS, Redis Streams или даже таблицы как временное хранилище. Отдельный воркер забирает события, формирует батчи для Google Sheets и бережно дозирует вызовы в Notion. Преимущества — устойчивость к всплескам, предсказуемые ретраи, гибкая трансформация данных. Если Sheet временно недоступен, событие не теряется, а повторится через бэкофф. Минусы — чуть больше инфраструктуры и настройка мониторинга. Но если речь про прод, именно так не сжечься на первом крупном трафике.

Практически: для MVP делайте прямой путь, для прод — webhook + очередь + worker. Это не догма, но статистика ошибок склоняет к второму варианту уже со 100–300 активных пользователей в день.

Аутентификация и доступ: без лишних прав и сюрпризов

Google Sheets понимает несколько способов доступа. Для серверных задач привычен сервисный аккаунт с OAuth2. Его удобно подключать к таблице через шаринг по e‑mail сервисного аккаунта и ограниченные скопы, чтобы у процесса не было лишних прав. Альтернатива — Apps Script, особенно если нужны правила внутри самой таблицы. Notion использует интеграционный токен: вы создаёте интеграцию в настройках, получаете секрет и даёте ей доступ к нужным базам или страницам через Share. Обязательно сохраните базовый id объекта, с которым будете работать.

Токены хранятся только в защищённых переменных окружения или менеджере секретов. Не в коде, не в логах, не в конфиге, который улетит на GitHub. Раз в квартал делайте ротацию токенов и скоупов. Для продакшена заведите отдельные интеграции и сервисные аккаунты, не используйте личные. Если вдруг логирование захватило секрет — действуйте как при инциденте: отзываете ключ, перекатываете систему, уведомляете команду. Прятать голову в песок поздно, лучше автоматически маскировать секреты в логах на уровне библиотеки.

Модель данных и идемпотентность: дисциплина, которая экономит время

Модель — это таблицы, колонки и свойства, которые вы согласуете до первого запроса. В Google Sheets определите фиксированный заголовок: дата, message_id, имя, телефон, источник, статус, ссылка на Notion. В Notion создайте базу с соответствующими полями: Name, Telegram Message ID, Phone, Status, Sheet Row URL. Не стесняйтесь добавить служебные поля: Updated At, Retry Count, Imported By. Это скучная часть, но она спасает от расхождений через месяц.

Идемпотентность — умение системы повторять одно и то же действие без дублирования результатов. В теле события храните idempotency_key, лучше всего это сочетание message_id и типа операции. Перед записью проверяйте, не существует ли уже такая строка или страница. В прямой интеграции можно сначала искать по индексу в Notion, а в таблице хранить скрытую колонку с ключом. В архитектуре с очередью логика ещё интереснее: первое создание помечаем как Upsert, повторный запрос превращаем в Update без добавления новых строк. И вот это как раз та мелкая деталь, которая делает систему предсказуемой при ретраях и случайных таймаутах.

Не забывайте про миграции схемы. Когда вы меняете свойства в Notion базе или переносите колонки в Sheets, старый код должен хотя бы не падать. Спасает кеширование схемы: при старте воркер один раз тянет список свойств базы и карту соответствий, складывает в память или быструю KV, и использует её до следующего TTL. Для критичных изменений предусмотрите фичефлаги и «сухой прогон» на тестовой базе.

Ограничения и производительность: дышим в ритм внешних API

Telegram, Google и Notion живут с квотами. Telegram не приветствует спам — есть лимиты на сообщения в секунду и на операции в одном чате. Значит, не стоит подтверждать каждую микрозапись отдельным сообщением, лучше объединять уведомления. Google Sheets любит пакетные операции: вместо десятков вызовов append по одной строке используйте batchUpdate, когда это возможно. Даже простой буфер из N записей, который раз в 2–5 секунд отправляется пачкой, здорово экономит квоты и ускоряет работу.

Notion более требователен к частоте запросов и размеру полезной нагрузки. Тут поможет троттлинг с экспоненциальным бэкоффом, а ещё — экономия на чтении. Если вы знаете схему и не вытаскиваете страницу целиком без нужды, нагрузка падает. Для больших потоков удобен подход «агрегатор–писатель»: накопили 50–200 событий, сформировали батч в таблицу, а страницы в Notion создаём только по ключевым триггерам. Вопрос логики: не каждый клик превращать в страницу, а только финальные состояния или важные вехи.

Кэшируйте справочники и схемы, отдавайте приоритет асинхронным подтверждениям, снижайте чатовую болтовню. Чтобы не превратиться в системного администратора, который ловит хвост квот, заведите метрики. Например, среднее время записи в Sheets и Notion, процент ретраев, текущую длину очереди, число падений по лимитам.

Наблюдаемость и откат: жизнь без чёрных ящиков

Логи — ваши дружественные следопыты. Логируйте входящие сообщения бота, ключевые этапы трансформации, статус записи в Sheets и статус создания страницы в Notion. Не надо писать туда телефоны и адреса целиком: хешируйте PII или маскируйте, чтобы не тащить к себе лишние риски. Присвойте каждой операции correlation_id, им может быть тот же message_id или его хэш. По нему удобно собирать всю историю события от вебхука до финальной записи.

Ошибки делятся на временные и фатальные. Временные автоматически уходят на ретрай с бэкоффом и ограничением по числу попыток. Фатальные требуют компенсации: если страницу в Notion создали, а таблица не записалась, воркер должен либо удалить страницу, либо пометить её как Orphaned и вернуть событие в очередь с низким приоритетом. Это не про перфекционизм, это про сохранение согласованности данных. На практике такие случаи редки, зато очень болезненны для аналитики.

Для поддержки добавьте простую переобработку. Нашли баг в трансформации — помечаете в таблице записи с конкретным тегом, кидаете их в переочередь и даёте воркеру обновить Notion и обратно. В Ticky AI мы держим небольшую админку на один экран: графики очереди, последние ошибки, кнопка «replay» для группы событий. На самом деле этого достаточно, чтобы перестать нервничать по ночам.

Два жизненных примера

Представим форму лидов. Пользователь пишет боту имя и телефон, иногда добавляет комментарий, а иногда нет. Бот валидирует номер, присваивает message_id и формирует запись. В таблицу уходит строка через append: дата, имя, телефон, источник lead_bot, статус New. Сервисный аккаунт видит таблицу, потому что заранее добавлен в доступы. Параллельно воркер создаёт страницу в Notion в базе CRM, в свойства кладёт все данные и ссылку на строку в Sheets. В обе записи попадает один и тот же ключ связки. Если от Telegram прилетит повтор — по ключу обновится статус, но новая строка не появится. Менеджер открывает Notion, меняет статус на Contacted — в таблице можно отразить это через периодическую синхронизацию статусов или вебхук из Notion, если он настроен.

Теперь опрос или анкетирование. Ответы приходят пачками, а часть вопросов многозначные. В боте их лучше складывать в буферную очередь, а не писать каждый ответ по отдельности. Каждые N записей воркер делает пакетную запись в Sheets, что раз в пять снижает число запросов. По итогам опроса формируется короткое резюме: общая оценка, ключевые метрики, выводы. Вот именно оно и превращается в страницу в Notion с аккуратной структурой, чек‑листом и тегами. В Ticky AI мы так собирали обратную связь на новые функции: таблица давала нам графики, а страницы в Notion — подробные истории с цитатами и контекстом. Ни одна выдающаяся фраза пользователя не потерялась.

Пошаговый план запуска: от нуля к надёжности

Начать просто. Для MVP в боте добавьте обработчик команд, проверьте валідацию полей и сделайте прямой вызов к Google Sheets через append, а к Notion — через создание страницы по id базы. Токены возьмите из секретов окружения, а id базы и url таблицы — из конфигурации, не из кода. Логи пишите в стандартный вывод, добавьте префикс с message_id. Этого хватит, чтобы в первый день собрать лиды и не ронять бота.

Когда пойдет трафик, поставьте вебхук на устойчивый endpoint и добавьте очередь. Redis Streams с подтверждениями или SQS — хорошее начало, они простые и понятные. Воркер делает батчи в Sheets через batchUpdate, а в Notion — дозированные create/update с троттлингом. Ошибки идут на ретрай с экспоненциальным бэкоффом. Идемпотентность держится на ключе из message_id: если событие уже обработали, воркер просто протоколирует «skip». Дальше — кеш схемы Notion с TTL, лёгкая админка и экспорт метрик. Так незаметно вы переходите от «лишь бы работало» к «работает и не мешает жить».

Риски и как их снизить

Главные риски понятны. Утечка токенов и персональных данных лечится дисциплиной секретов, маскированием логов и изоляцией окружений. Рассинхронизация при сбоях уходит при идемпотентности и компенсирующих операциях. Блокировки за превышение лимитов смягчаются батчами, очередями и троттлингом. Изменения схемы в Notion или Sheets ломают интеграцию, если код жёстко привязан к именам свойств; от этого спасает кеш схемы, фичефлаги и тестовая база. И конечно, требования GDPR и локальные законы. Не собирайте лишнего, храните только то, что нужно, ставьте срок жизни данным, удаляйте по запросу. Ничего героического, просто базовый гигиенический набор.

Когда что выбирать: короткий ориентир

Если вы запускаете пилот, интеграция Telegram бота с Google Sheets и Notion через прямые вызовы — самый верный старт. Вам не нужна лишняя инфраструктура, а скорость разработки выше. Когда появятся первые боли с ретраями и лимитами, переносите запись в очередь и воркеры. Это не революция, а эволюция, которая проходит без боли, если у вас есть идемпотентные ключи и нормальная модель данных. По дороге добавляйте батчи для Sheets и умное кэширование схемы Notion. Проверяйте логи от конца к началу — иногда один странный символ в поле ломает операцию.

Небольшой штрих про Ticky AI

Мы строили связку для контентных заявок: пользователи кидали боту темы, ссылки, приоритет. В Sheets появлялась строка с краткими данными и метаданными, а в Notion — страница карточки с чек‑листом по подготовке. На первых итерациях мы работали через прямые вызовы, но как только поняли, что отзывы идут волнами, переключились на очередь. Идемпотентность на message_id, батчи в таблицу, кеш схемы Notion раз в 15 минут. На всё ушло пару вечеров, зато дальше команда занялась контентом, а не шаманством с упавшими запросами. Рекламы здесь нет, просто опыт, который сэкономил нервы.

Если хочется увидеть, как это ощущается со стороны пользователя, загляните в нашего бота: t.me/TickyAI_bot.

Тихая развязка

Интеграции редко бывают идеальными с первого захода. Но если разделить систему на чёткие кусочки, обуздать доступы, заранее договориться о схеме и не забывать про бэкофф с очередями, вы получаете устойчивую машину, которая не подводит в пиковые дни. Таблица даёт широкую панораму, Notion — глубину и контекст. Telegram — ваш живой интерфейс к этим двум мирам.

Два мягких совета напоследок. Не пытайтесь автоматизировать всё в первый день, начните с одного сценария и доведите его до надёжности. И второй — пишите короткие примечания в коде рядом с местами, где делаете компромиссы. Через месяц вы сами себе скажете спасибо.

FAQ

Q: Можно ли обойтись одним Google Apps Script без сервера?

A: Для простых сценариев — да. Скрипт по вебхуку может принимать запрос из бота и писать в таблицу, а для Notion использовать внешний вызов через fetchUrl. Но как только нужна очередь, ретраи и идемпотентность на уровне событий, удобнее вынести логику на отдельный воркер.

Q: Что делать, если изменили свойства в Notion и всё «сломалось»?

A: Внедрите слой сопоставления: внутренние имена полей в вашем коде мапятся на текущие свойства базы, которые вы подгружаете и кэшируете. Менять нужно маппинг, а не весь код. Плюс держите тестовую базу для «сухих» миграций и прогоняйте пару десятков записей перед выкатыванием.

Q: Make или n8n вместо собственного кода?

A: Это нормальный выбор для старта и прототипов: быстро, понятно, с визуальными ретраями. Обратная сторона — контроль и масштабирование. Если важны строгие лимиты, тонкий троттлинг, сложные батчи, рано или поздно вы упрётесь в границы платформы и перенесёте ядро на свой воркер. Хорошо, когда вы это учитываете заранее и храните идемпотентные ключи одинаково по обе стороны.

Готовы ускорить заявки и перестать копировать данные руками? Запускайте бота прямо сейчас: t.me/TickyAI_bot.