Як зв’язати CRM, сайт, склад і облік, щоб дані не розходилися

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

КОРОТКО

Чому ламаються інтеграції

Інтеграція залишається надійною, коли кожен вид даних має одну систему-власника, кожне повідомлення зберігається до обробки, повторна обробка нічого не псує, завдання за розкладом порівнює системи й виправляє розбіжності, а людина отримує сповіщення, якщо щось зупинилося. Скрипт «точка до точки» за замовчуванням нічого з цього не має. Тому в день запуску він працює, а потім губить замовлення, створює дублі й розходиться з реальністю, часто тижнями, перш ніж хтось це помітить.

З боку власника це виглядає буденно. На сайті три штуки, на полиці порожньо. Бухгалтер вручну передруковує рахунки, бо «синхронізація частину пропускає». Менеджер телефонує клієнту щодо неоплаченого замовлення, яке той оплатив у вівторок. Повідомлення про помилку ніхто не бачив: збій стався між двома системами, а за цей проміжок не відповідає жодна з них.

Прямий скрипт найдешевший на старті, і для двох систем його може вистачити. Далі заважає арифметика: трьом системам може знадобитися три зв’язки, п’яти вже десять, і кожен має свій логін і своє уявлення про те, хто такий клієнт. Додайте до сайту, CRM, складу й обліку ще Нову пошту та еквайринг, і вийде шість систем та до п’ятнадцяти зв’язків.

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

Інтеграція, що працює в день запуску, пройшла лише найлегший тест.

ЯК ЛАМАЮТЬСЯ

Чотири збої, яких ніхто не бачить

Втрачені повідомлення. Більшість сучасних систем повідомляє про зміни через вебхук: коротке повідомлення на ваш сервер, коли щось сталося. Якщо сервер недоступний, відправник якийсь час повторює спроби й здається. Shopify повторює до восьми разів за чотири години, а якщо збої тривають, видаляє підписку, і нові події взагалі перестають надходити, доки її не створять знову (Shopify, листопад 2026). Еквайринг monobank робить до трьох повторних спроб, якщо не отримав відповідь HTTP 200 OK (monobank, листопад 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 року, і вони змінюються. Думка живе довше: будь-який відправник у якийсь момент здається й очікує, що недоставлене ви відновите самі. Три спроби monobank означають, що навіть коротке оновлення сервера без черги вже небезпечне.

ОДИН ВЛАСНИК

У кожної цифри один власник

Перш ніж писати код, запишіть, яка система володіє кожним видом даних. Якщо дві системи можуть змінювати одну цифру незалежно, вони розійдуться, а синхронізація лише швидше копіює розбіжність. Загальну логіку систем-джерел описано у статті Цифрова архітектура: як побудувати систему, що росте разом з бізнесом. На практиці рішення вміщуються на одній сторінці:

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

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

Як це виглядає в наших проєктах. Для клієнта в e-commerce, у якого продажі працюють у Salesforce, а відвантаження в окремій складській системі, ми зробили власний шар, що синхронізує замовлення в обидва боки без ручного введення; жодна система не була зламана, тому жодну не замінили. Платформа Honda Ukraine пов’язана з внутрішніми CRM і складськими системами Honda, тож дані про продукцію й робота дилерів залишаються узгодженими. Її запущено у 2019 році, вона використовується й понад шість років потому, і наша команда її підтримує. У FIAT Kharkiv залишки синхронізуються з 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, а в тілі вебхука monobank є modifiedDate. Наше практичне правило випливає з цього всього: вважайте вебхук сигналом про те, що щось змінилося, а поточний стан читайте в системі-власника. Тоді старе повідомлення не перезапише новіший статус.

ЗВІРКА

Порівнювати системи щоночі

Звірка ловить те, чого не впіймають черги й ключі: завдання за розкладом порівнює системи й повідомляє про розбіжності або виправляє їх. Shopify каже про це прямо: доставка вебхуків гарантована не завжди, тому застосункам не варто покладатися лише на них, а треба запускати завдання звірки, які періодично забирають дані, використовуючи фільтри updated_at для отримання змін із минулого запуску (Shopify, листопад 2026).

Для кожного виду даних завдання запитує у власника, що змінилося, порівнює це із системами-отримувачами й розкладає результат: виправлено автоматично або чекає на людину. Типові перевірки й частота, з якої ми б почали:

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

Журнали й сповіщення замикають коло. Кожне повідомлення має залишати слід: звідки прийшло, куди пішло, його ключ, спроби, результат і текст помилки. Сповіщення йдуть тому, хто може діяти, з короткою підказкою, що робити насамперед. Сповіщення, яке спрацьовує щодня й не потребує дій, лагодять або прибирають, бо воно привчає команду ігнорувати наступне.

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

Збійний скрипт шумить. Відключений мовчить, тому стежте за тишею.

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

Версії, пісочниці й тренування

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

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

Тестуйте в пісочницях і пам’ятайте про їхні межі. Пісочниці 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