Связываю CRM, 1С, маркетплейсы, мессенджеры и внешние сервисы в единый поток. Делаем собственные REST API, подключаем webhook, ставим очереди, логирование и мониторинг - чтобы данные ходили между системами без потерь и без ручных выгрузок Excel.
От 100+ заказов в день. Каталог в 1С или «Моём складе», продажи на Wildberries, Ozon, Авито и собственном сайте. Без интеграции - двойной ввод цен, остатков и отгрузок руками.
Заявки приходят из 3–5 источников: форма, чат, телефония, реклама, маркетплейс лидов. Менеджерам нужно видеть всё в одной CRM с источником и UTM - без копипасты.
Биллинг → CRM → телефония → бухгалтерия. Когда счета и статусы ходят между четырьмя сервисами руками, теряется минимум 1 день в неделю и появляются ошибки в начислениях.
Когда часть процесса в 1С, часть в Google Sheets, часть в почте. Интеграция убирает «человека-мост» и делает данные единым источником истины для отчётов.
Если кто-то в команде переносит данные из формы в CRM, из CRM в 1С, из 1С в отчёт - посчитайте часы. Обычно это 4–8 часов в неделю на одного человека.
Заявка с Авито попала на почту - никто не увидел вовремя. Чат в WhatsApp не дошёл до CRM. Менеджер не успел перезвонить - лид ушёл к конкуренту.
Один и тот же товар продан дважды на разных площадках, отгрузка задерживается, штрафы за просрочку. Это значит, что синхронизации стоков нет или она работает раз в час.
Если в последнюю пятницу кто-то 4–6 часов сводит выгрузки из CRM, 1С и рекламных кабинетов - это задача для API-интеграции и автоматического отчёта.
Базовая схема: одна сторона отдаёт данные по REST, другая принимает webhook на изменение. Подходит для большинства CRM, маркетплейсов и платёжных систем.
Когда объёмы большие или внешний API нестабилен - данные идут через очередь. Ретраи, экспоненциальная задержка, dead-letter queue для ручного разбора редких ошибок.
FastAPI или Node.js - когда внешним системам нужно тянуть данные из вашей. Авторизация, версионирование, rate limit, документация Swagger/OpenAPI.
Если у системы нет публичного API - собираем мост через парсер или эмуляцию интерфейса. Обычно временное решение до появления нормального API.
Смотрим системы-источники и приёмники, читаем документацию API, фиксируем, какие поля и в какую сторону должны идти. На выходе - диаграмма потока данных и список рисков.
Описываем сценарии, маппинг полей, обработку ошибок и пограничные случаи. Даём фиксированную оценку по срокам и бюджету. Без этого этапа в разработку не идём.
Поднимаем dev-окружение, пишем коннекторы, ставим очереди и логирование. Прогоняю тестовые сценарии - нормальный поток, ошибки, повторы, edge-cases.
Переключаем боевые системы, первые дни - особое внимание к логам. Передаём документацию команде. Дальше - сопровождение по запросу или регулярная поддержка.
Для собственных API и сложной бизнес-логики. Асинхронность, типизация, авто-документация Swagger/OpenAPI из коробки. Хорошо ложится на интеграции с LLM и аналитикой.
Когда сценарий - это «прочитать webhook → дёрнуть три API → записать в таблицу». Быстрее, чем кодить с нуля. Сценарии видит команда, можно править без программиста.
Когда инфраструктура клиента уже на Node или нужен один runtime с фронтендом. Express/Fastify, очереди через BullMQ, строгая типизация контрактов между сервисами.
Очереди - для устойчивости, dead-letter queue - для редких ошибок, Sentry - для алертов. Grafana - дашборд метрик: время отклика, количество ошибок, объёмы.
Опишите процесс - посмотрим системы и скажем честно: где интеграция окупится за пару месяцев, а где проще оставить ручной режим.
Типичный результат - освобождение 1–2 рабочих дней в неделю у менеджера или операциониста. Эти часы возвращаются в продажи, обработку клиентов и развитие.
Все заявки попадают в CRM с источником, UTM и временем. Менеджер видит SLA, руководитель - конверсию по каналам. Никто не выпадает из воронки.
Остатки на маркетплейсах = остаткам в 1С. Оплаты в CRM = выпискам банка. Не нужно объяснять расхождения по понедельникам и пересчитывать вручную.
Все запросы между системами логируются. Если что-то пошло не так - видно когда, что и почему. Не «у нас всё сломалось», а «вот лог, вот фикс».
Работаем с любыми REST/JSON API - CRM (Bitrix24, amoCRM, HubSpot), 1С, маркетплейсы (Wildberries, Ozon, Яндекс.Маркет), мессенджеры (Telegram, WhatsApp Business), платёжные системы, ЕГРЮЛ/ЕГРИП, банки, email-провайдеры. Если у системы есть документация - подключим. Если документации нет, делаем reverse engineering или ставим парсер как мост.
И то, и другое. Собственный API нужен, когда внешний сервис должен забирать данные из вашей системы - например, сайт на тильде шлёт лиды, мобильное приложение тянет каталог, партнёры получают остатки. Стек - Python (FastAPI), Node.js или PHP в зависимости от вашей инфраструктуры.
Каждая интеграция - это очередь с ретраями, логирование запросов и ответов, мониторинг ошибок и алерты. Если внешний API упал - данные не теряются, дозальются после восстановления. На критичных потоках ставим dead-letter queue и ручную обработку для редких исключений.
OAuth2, API-ключи, JWT, подпись webhook - по требованиям конкретного сервиса. Секреты хранятся в переменных окружения или vault, не в коде. Для собственных API - rate limiting, валидация входных данных, аудит-лог. HTTPS обязательно, IP-белый список - где это уместно.
Зависит от количества полей, сложности маппинга и наличия документации. Простая односторонняя интеграция (например, лид с сайта в CRM) - короткий проект. Двусторонняя синхронизация остатков между складом и тремя маркетплейсами - больше. Точную оценку дадим после короткого аудита процесса и систем.
Простая односторонняя интеграция (форма → CRM, webhook → таблица) - обычно 3–7 рабочих дней с аудита до боевого запуска. Двусторонняя синхронизация с очередями и обработкой ошибок - 2–4 недели. Большие проекты с маркетплейсами и десятком endpoint-ов - от месяца. Точный срок даём после ТЗ.
Сначала проверяем, нет ли неофициального способа - например, скрытого endpoint-а у админ-панели или экспорта в файл по расписанию. Если ничего нет, ставим мост через парсер с эмуляцией браузера и приоритетом на устойчивость. Это рабочий, но временный вариант - рекомендуем параллельно запрашивать API у вендора.
Два формата. Первый - разовая поддержка по запросу: что-то сломалось - пишете в Telegram, в течение рабочего дня разбираем. Второй - регулярное сопровождение с SLA: мониторинг, плановые правки, доработки. Подбираем под объём интеграций и критичность процесса.
Опишем схему обмена данными между вашими системами и покажем, сколько займёт каждая интеграция. Без обязательств.
