Как связать CRM, сайт, склад и учёт, чтобы данные не расходились

Как связать CRM, сайт, склад и учёт так, чтобы цифры оставались верными? Большинство интеграций работает в день запуска, а потом данные расходятся, и ошибку никто не видит. Рассказываем простыми словами, как именно они ломаются и какие механизмы это останавливают. Отдельно разбираем реальные лимиты API, случаи, когда хватает no-code инструментов, и вопросы к подрядчику.

КОРОТКО

Почему ломаются интеграции

Интеграция остаётся надёжной, когда у каждого вида данных одна система-владелец, каждое сообщение сохраняется до обработки, повторная обработка ничего не портит, задача по расписанию сравнивает системы и исправляет расхождения, а человек получает оповещение, если что-то остановилось. У скрипта «точка к точке» ничего этого по умолчанию нет. Поэтому в день запуска он работает, а потом теряет заказы, плодит дубли и расходится с реальностью, часто неделями, прежде чем кто-то это заметит.

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

Прямой скрипт дешевле всего на старте, и для двух систем его может хватить. Дальше мешает арифметика: трём системам может понадобиться три связи, пяти уже десять, и у каждой свой логин и своё представление о том, кто такой клиент.

Сколько из описанного ниже нужно вам, зависит от цены одной ошибочной записи. Дубль подписки на рассылку не стоит ничего. Оплаченный заказ, не дошедший до склада, стоит клиента.

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

КАК ЛОМАЮТСЯ

Четыре сбоя, которых никто не видит

Потерянные сообщения. Большинство современных систем сообщает об изменениях через вебхук: короткое сообщение на ваш сервер, когда что-то произошло. Если сервер недоступен, отправитель какое-то время повторяет попытки и сдаётся. Shopify повторяет до восьми раз за четыре часа, а если сбои продолжаются, удаляет подписку, и новые события перестают приходить вообще, пока её не создадут заново (Shopify, ноябрь 2026). Сервер, лежавший с вечера субботы до утра воскресенья, может потерять эти заказы и саму связь, а в понедельник всё выглядит спокойно.

Дубли. Одно и то же сообщение может прийти дважды. Отправитель повторяет его, потому что ваш ответ опоздал на секунду, хотя код уже сделал работу. Stripe прямо пишет, что обработчик может получить одно событие больше одного раза. Без защиты один заказ превращается в два счёта.

Лимиты запросов. Любой API ограничивает скорость обращений. На аккаунте HubSpot Professional приложение с приватным распространением получает 190 запросов за 10 секунд, а аккаунт 625 000 в сутки; сверх этого HubSpot отвечает статусом 429, то есть «слишком много запросов» (HubSpot, ноябрь 2026). Передача 40 000 изменённых записей по одному вызову займёт около 35 минут даже на полном лимите. Скрипт, который не обрабатывает 429, отчитается об успехе по первой части и потеряет остальное.

Изменившиеся поля. Менеджер делает поле в CRM обязательным, переименовывает статус «Оплачен» в «Оплата получена», или поставщик выпускает новую версию API. Скрипт продолжает работать и пишет пустые значения либо перестаёт что-либо находить. Shopify выпускает версию API раз в три месяца и поддерживает каждую стабильную минимум 12 месяцев. Когда версию отключают, Shopify отвечает самой старой из ещё доступных стабильных, поэтому старый код получает новое поведение совсем без ошибки, меняется только заголовок X-Shopify-API-Version (Shopify, ноябрь 2026).

Сроки задаёт отправитель, и интеграция должна в них укладываться:

Цифры поставщиков на ноябрь 2026 года, и они меняются. Мысль живёт дольше: любой отправитель в какой-то момент сдаётся и ожидает, что недоставленное вы восстановите сами. Если у вашего платёжного провайдера в регионе правила не описаны, как в случае Tap, спросите о них до начала работы.

ОДИН ВЛАДЕЛЕЦ

У каждой цифры один владелец

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

Оптовый канал или партнёрская программа меняют распределение ролей, об этом статья Когда e-commerce становится бизнес-системой. У компании, которая ведёт закупки и производство внутри CRM, вопрос другой, он разобран в статье CRM и ERP: в чём разница и какая система нужна вашему бизнесу.

Двусторонняя синхронизация заслуживает подозрения: часто она означает, что никто не принял решение. Когда данные всё же идут в обе стороны, владельца назначают для каждого поля: сумма заказа идёт в одну сторону, статус доставки в другую.

Как это выглядит в наших проектах. Для клиента в e-commerce, у которого продажи работают в Salesforce, а отгрузка в отдельной складской системе, мы сделали собственный слой, который синхронизирует заказы в обе стороны без ручного ввода; ни одна система не была сломана, поэтому ни одну не заменили. Платформа Honda Ukraine связана с внутренними CRM и складскими системами Honda, так что данные о продукции и работа дилеров остаются согласованными. Она запущена в 2019 году, используется и спустя более чем шесть лет, и наша команда её поддерживает. В дилерском центре FIAT остатки синхронизируются с CRM, и задача там состояла в том, чтобы всё работало и после обновления CRM; оба проекта разобраны в статье Клиент видит автомобильный каталог. Бизнес управляет системой жизненного цикла.

Самое сильное решение состоит в том, чтобы связей было меньше. Для LavShash, где есть ресторан, маркет примерно на 2 000 или 3 000 товаров и собственная доставка, мы спроектировали одну систему с тремя сценариями вместо трёх продуктов, которые пришлось бы синхронизировать; система построена, запуск отложен. Логика решения описана в статье Ресторан, интернет-магазин и доставка: одна система или три продукта?

ОЧЕРЕДИ И ПОВТОРЫ

Сначала сохранить, потом обработать

Когда приходит сообщение, сервер делает только три вещи: проверяет подпись, сохраняет сообщение и отвечает «получено». Настоящая работа (создать счёт, обновить остаток) выполняется позже, фоновым процессом, который читает очередь.

Поставщики просят именно этого. Stripe требует вернуть статус 2xx до любой сложной логики и в качестве примера приводит отметку об оплате счёта в вашей учётной системе: сначала ответ, потом это. Он же рекомендует асинхронную очередь, чтобы всплеск в начале месяца не обрушил серверы. Shopify даёт пять секунд, а учётной системе легко может понадобиться больше.

Очередь ещё и даёт управляемые повторы. Если учётная система час недоступна, сообщения ждут, а потом уходят с той скоростью, которую она выдерживает. Безопасность обеспечивают три правила:

• С каждым сбоем ждать дольше, с долей случайности. Инженеры AWS называют это backoff with jitter и предупреждают, что наложенные друг на друга повторы умножают нагрузку: в их примере независимые повторы на каждом уровне поднимают нагрузку на базу данных в 243 раза.
• Соблюдать названный лимит. Ответ 429 может содержать заголовок Retry-After, который говорит, сколько ждать (RFC 6585). Shopify рекомендует подождать одну секунду. HubSpot просит, чтобы ответы с ошибками составляли меньше 5% суточных запросов.
• После заданного числа попыток откладывать сообщение. Сообщение, упавшее десять раз, обычно содержит проблему, которую повтор не исправит, например клиента без налогового номера. Оно попадает в отдельный список, часто его называют dead-letter queue, где человек может его прочитать, исправить и отправить снова.

То же относится к тому, что отправляет ваша собственная система. Если вы сохранили заказ, а затем вызвали CRM, сбой между этими шагами теряет вызов. Шаблон transactional outbox записывает исходящее сообщение в базу данных в той же транзакции, что и заказ, а доставляет его отдельный процесс. На собственном сайте мы применяем эту идею в простейшем виде: каждая заявка пишется в журнал до отправки письма, поэтому сбой почты её не потеряет. В статье Сколько тестирования нужно сайту или приложению перед запуском? рассказано, как форма могла бы благодарить посетителей, пока все письма исчезают.

Сначала ответ, потом работа, а сообщение хранится, пока работа не сделана.

ИДЕМПОТЕНТНОСТЬ

Безопасно получить дважды

Идемпотентность звучит неуклюже, а означает простое свойство: сделать что-то дважды значит получить тот же результат, что и один раз. Пять нажатий на кнопку лифта вызывают один лифт. Повторы неизбежны, и документация AWS к собственному сервису очередей говорит, что сообщение может быть доставлено снова и приложения нужно проектировать с учётом этого.

Вот сбой, который это предотвращает. Ваша система просит учётную создать счёт. Счёт создан, но ответ теряется из-за обрыва соединения. Ваша система видит таймаут и повторяет запрос, и счетов становится два.

Лекарство называется ключ идемпотентности: уникальная метка в запросе, по которой получатель понимает, что уже сделал эту работу. Так устроен API Stripe. Он принимает ключ длиной до 255 символов в POST-запросах, сохраняет результат первого запроса и при повторе возвращает его же. Если параметры отличаются от исходных, он отвечает ошибкой. Ключи могут удаляться, когда им исполнится минимум 24 часа, поэтому они защищают от повторов, но не заменяют ваши собственные записи (Stripe, ноябрь 2026).

Там, где принимающая система не предлагает ничего настолько удобного, защита переходит на вашу сторону:

• Стройте ключ из делового факта: система-источник, номер заказа и операция, например shop-1042-create-invoice. Случайное значение на каждую попытку не защищает ни от чего, а личные данные вроде email Stripe советует в ключи не помещать.
• Храните обработанные ключи в таблице базы данных с уникальным ограничением, чтобы два одновременных процесса не могли выиграть оба, и сохраняйте идентификатор, который вернула другая система.

Порядку нужно то же внимание. Stripe предупреждает, что invoice.paid может прийти раньше события о создании счёта и что его отметка created, в целых секундах, не годится для сортировки; он советует отслеживать идентификаторы событий и получать недостающие объекты через API. Shopify предлагает заголовок X-Shopify-Triggered-At или поле updated_at. Наше практическое правило следует из обоих: считайте вебхук сигналом о том, что что-то изменилось, а текущее состояние читайте у системы-владельца. Тогда старое сообщение не перезапишет более новый статус.

СВЕРКА

Сравнивать системы каждую ночь

Сверка ловит то, что не поймают очереди и ключи: задача по расписанию сравнивает системы и сообщает о расхождениях или исправляет их. Shopify говорит об этом прямо: доставка вебхуков гарантирована не всегда, поэтому приложениям не стоит полагаться только на них, а нужно запускать задачи сверки, которые периодически забирают данные, используя фильтры updated_at для получения изменений с прошлого запуска (Shopify, ноябрь 2026).

Для каждого вида данных задача спрашивает у владельца, что изменилось, сравнивает это с системами-получателями и раскладывает результат: исправлено автоматически или ждёт человека. Типичные проверки и частота, с которой мы бы начали:

• заказы за день в магазине против CRM и склада, по количеству и сумме, каждую ночь;
• оплаченные суммы у платёжного провайдера против счетов в учёте, каждую ночь;
• остаток по каждому SKU в складской системе против магазина, каждый час или чаще, если товар быстро заканчивается;
• действующие цены в ERP против магазина, после каждого массового изменения.

Журналы и оповещения замыкают круг. У каждого сообщения должен быть след: откуда пришло, куда ушло, его ключ, попытки, результат и текст ошибки. Оповещения идут тому, кто может действовать, с короткой подсказкой, что делать в первую очередь. Оповещение, которое срабатывает каждый день и не требует действий, чинят или убирают, потому что оно приучает команду игнорировать следующее.

Чаще всего интеграциям не хватает оповещения о тишине. Следите за деловым сигналом: за последний час рабочего дня в CRM не пришло ни одного заказа, очередь растёт уже двадцать минут, последняя успешная сверка была два дня назад.

Сбойный скрипт шумит. Отключившийся молчит, поэтому следите за тишиной.

КОНТРАКТЫ И ТЕСТЫ

Версии, песочницы и учения

Каждой связи нужен письменный контракт: какие поля передаются, их типы, какие обязательны, какие значения допустимы, кто ими владеет и что происходит с неизвестным значением. Одной страницы на поток достаточно, она хранится вместе с кодом и открывается, когда менеджер просит переименовать статус.

Указывайте версию API в каждом вызове, как советует Shopify, и считайте её ежеквартальный выпуск задачей в календаре. Stripe определяет структуру события по версии API в настройках аккаунта в момент события, поэтому обновление аккаунта может изменить то, что получает ваш обработчик. Тест в конвейере сборки, проверяющий форму каждого ответа, сообщит об этом в тот же день.

Для компаний в ОАЭ такой контракт скоро появится и с регулятором. Система электронных счетов обязательна с 1 января 2027 года для бизнеса с выручкой от 50 млн дирхамов и с 1 июля 2027 года для остальных; крупным компаниям нужно было назначить аккредитованного провайдера до 30 октября 2026 года. Модель построена на стандарте PEPPOL с пятью участниками, напрямую к государственной инфраструктуре подключиться нельзя, а учётные системы должны уметь формировать структурированные счета и обрабатывать ответы провайдера и налоговой (EY, сентябрь 2025; Gulf News, июнь 2026). Операции B2C освобождены до отдельного уведомления (KPMG, октябрь 2025). Это ещё одна связь с учётной системой, и если счёт сегодня создаётся в двух местах, сначала придётся решить, какое из них главное. Сроки и обязанности уточняйте у своего налогового консультанта.

Тестируйте в песочницах и помните об их границах. Песочницы Stripe имитируют платежи без движения реальных денег, но повторяют вебхуки три раза за несколько часов, тогда как в рабочем режиме до трёх дней. Песочница показывает, что код понимает сообщения. Как бизнес переживёт сбой, показывают учения на тестовой копии:

• выключить получателя на шесть часов и проверить, что ничего не потеряно;
• отправить каждое сообщение дважды и в неправильном порядке.

В проектах магазинов мы до запуска тестируем массовые обновления, задержку между ERP и витриной, восстановление после сбоя интеграции и синхронизацию в пик заказов. Лучше узнать на тестовой копии, что сделает первый настоящий сбой в субботу.

КАКОЙ ИНСТРУМЕНТ

Zapier, Make, n8n или свой код

Цены и лимиты взяты со страниц поставщиков на ноябрь 2026 года:

Две детали стоит проверить, прежде чем доверять заказы no-code инструменту. В Make упавший запуск сохраняется, чтобы данные не пропали, но когда это хранилище заполнено, Make отбрасывает данные об упавших запусках и продолжает работу сценария, а восстановить их нельзя. В Zapier при включённой оплате сверх лимита работа продолжается по повышенной ставке, но полностью останавливается на тройном объёме подписки до следующего периода. Эти условия лучше знать до самого загруженного дня в году.

Посчитайте свой поток. Возьмём 10 000 заказов в месяц по пять шагов-действий: это 50 000 задач в Zapier, $289 в месяц при оплате за год или $433.50 при помесячной, и 10 000 выполнений на тарифе Pro в n8n. По сравнению с разработчиком деньги скромные, поэтому решающий вопрос в другом: кто спроектирует идемпотентность, сверку и оповещение о тишине.

Обычно мы советуем разделение: no-code для уведомлений и маркетинговых списков, где пропуск стоит дёшево, и код для заказов, платежей, остатков и счетов. Случается, что свой код вообще не нужен. Для клиента в сфере профессиональных услуг, уверенного, что ему необходима своя CRM, мы описали трёхэтапный процесс продаж и рекомендовали настроенный HubSpot: две недели настройки вместо месяцев разработки. Заменить систему или связать её с другими, разобрано в статье Своя CRM или ERP: когда готовой системы уже мало.

Когда собственный слой оправдан, он строится вокруг того, как работает ваш бизнес, а код, команды развёртывания, процедура отката и файл AGENTS.md с описанием правил передаются вам по договору. Со временем слой может вырасти: Разработка CRM от $30 000, Разработка ERP от $50 000, Разработка веб-приложений и SaaS от $25 000. Мы не продаём интеграцию как отдельную техническую работу, потому что самые полезные решения в ней, например кто владеет ценой, относятся к бизнесу.

ЧТО СПРОСИТЬ

Вопросы к подрядчику

Хороший ответ конкретен и сопровождается тем, что можно посмотреть.

1. Какая система владеет каждым полем? Попросите показать таблицу.
2. Что будет, если наш сервер недоступен шесть часов? Слушайте про очередь и про то, как возвращаются пропущенные события.
3. Что будет, если одно сообщение придёт дважды или не по порядку? Спросите, какой ключ предотвращает дубль счёта.
4. Какой лимит у каждого API и что делает синхронизация при 429? Спросите, сколько длится полное обновление каталога.
5. Как часто вы делаете сверку и где мы увидим расхождения? Попросите пример отчёта.
6. Кто получает оповещение и как мы узнаем, что связь замолчала?
7. Какие версии API зафиксированы и кто следит за их отключением?
8. Какие сбои вы тестируете? Попросите список учений, включая отключение.
9. Что мы получаем в конце? В списке должны быть код, документация и контракт каждого потока.

Сколько это стоит в Peretz Agency. Связь между существующими системами обычно выполняется как работа на Laravel за $75 в час или как проект с фиксированной ценой от $15 000; цена зависит от числа систем, качества их API и объёма данных для очистки. Discovery-фаза от $4 000, от двух до четырёх недель, описывает интеграции и риски и превращает их в бэклог с бюджетом. Если разработчик доставшейся вам интеграции ушёл, аудит перед приёмом от $2 500 записывает, что с чем связано. Поддержка от $1 000 в месяц. Обычный первый шаг это стратегическая сессия за $500, которая засчитывается в проект в течение 30 дней.

FAQ

Источники

• Stripe: Receive Stripe events in your webhook endpoint
• Stripe: Idempotent requests
• Shopify: Webhook best practices
• HubSpot: API usage guidelines and limits
• Microservices.io: Transactional outbox pattern