Замовлення є на сайті, але його немає в CRM: де губляться дані

Покупець оформив замовлення, сайт показав сторінку підтвердження, запис зберігся в адмінпанелі магазину. Менеджер відкриває CRM, а нового замовлення там немає. У такій ситуації проблема не обов'язково виникла в CRM і не обов'язково пов'язана із сервером сайту. Спочатку треба знайти етап, на якому конкретне замовлення перестало рухатися.

Між кнопкою "Оформити замовлення" і новим записом у CRM може бути кілька ланок: сайт, модуль інтеграції, webhook або API, черга, фонове завдання, API CRM і внутрішня обробка вже в самій CRM. Збій на будь-якому з цих етапів може пройти непомітно для покупця.

Найкраща точка відліку для діагностики - ID конкретного замовлення та точний час його створення. З ними можна послідовно з'ясувати, чи запустилася інтеграція, чи був відправлений запит, що відповіла CRM і чи створила вона запис.

Замовлення на сайті вже є. Що мало відбутися далі

Якщо замовлення є на сайті, але його немає в CRM, це ще не означає, що проблема виникла на боці CRM. Створення запису в CMS і передавання цього запису в іншу систему - дві окремі події.

Після оформлення замовлення сайт має запустити інтеграційний механізм. У різних проєктах він працює по-різному: одразу викликає API CRM, формує webhook, додає завдання в чергу або чекає наступного запуску cron чи scheduler. Іноді передавання починається не відразу після оформлення, а лише після зміни статусу, наприклад після підтвердження оплати.

У спрощеному вигляді маршрут такий: сайт → модуль інтеграції → API або webhook → черга чи фонове завдання → CRM. Тому перше питання не "чому CRM не бачить замовлення", а "чи замовлення взагалі вийшло із сайту". Якщо в журналі інтеграції немає навіть спроби передавання конкретного order ID, аналізувати відповідь CRM ще зарано.

Для початку варто з'ясувати, що саме запускає синхронізацію у вашому магазині: миттєвий API-запит, webhook, cron, окремий worker або модуль інтеграції. Без цього діагностика швидко перетворюється на випадкову перевірку всього підряд.

Дані могли загубитися ще до першого запиту до CRM

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

Як зрозуміти, що завдання залишилося в черзі

У журналах інтеграції знайдіть потрібний order ID і подивіться стан пов'язаного завдання. Позначки pending, failed і completed ведуть у різні боки. Pending зазвичай означає, що завдання ще чекає виконання. Failed показує, що спроба була, але завершилася помилкою. Completed варто звіряти з відповіддю API, бо завершене фонове завдання ще не гарантує створення запису в CRM.

Якщо завдання все ще pending, до CRM воно могло навіть не дійти. Для WooCommerce типовою точкою перевірки може бути Action Scheduler, для інших систем - власна черга, системний scheduler або окремий queue worker. Також корисно звірити час створення замовлення з часом останнього запуску cron.

Чим затримка відрізняється від повної втрати синхронізації

Якщо замовлення не зникли повністю, а почали з'являтися в CRM із затримкою, першою підказкою буде черга або scheduler. Коли синхронізація відбувається через десятки хвилин після оформлення, це більше схоже на накопичення завдань або нерегулярний запуск cron, ніж на неправильний API-key.

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

Сайт відправив замовлення, але CRM його відхилила

Якщо API-запит справді пішов із сайту, наступна точка перевірки - відповідь CRM. Повторний запуск cron не допоможе, якщо CRM уже отримала запит і відхилила його через авторизацію, неправильні дані або зміну API.

Помилки авторизації

Коди 401 і 403 часто вказують на проблеми з доступом: неправильний API-key, прострочений access token, недостатні права або обмеження за IP. Після зміни токена симптом зазвичай стабільний: перестають синхронізуватися всі нові замовлення, а не окремі випадкові записи.

Помилки даних і обов'язкових полів

CRM може відхилити запит, якщо не передано обов'язкове поле, значення має неправильний формат або вказаний невідомий ID складу, доставки, менеджера чи способу оплати. Код 400 часто пов'язаний із некоректними даними, 422 - із бізнес-перевіркою, а 409 у деяких API використовується для конфлікту або дубля. Точне значення відповіді треба звіряти з документацією конкретної CRM.

Що перевіряти після зміни API

Після оновлення CRM або інтеграційного модуля варто звірити endpoint, HTTP-метод, версію API і формат payload. Код 404 може вказувати на неправильну адресу endpoint, 429 - на перевищення ліміту запитів, а 500, 502 або 503 - на проблему в API або проміжній інфраструктурі.

Для діагностики потрібні не лише HTTP status, а й тіло відповіді (response body), error code, timestamp, endpoint, request ID і ID замовлення сайту. Практичне правило просте: дивимося не тільки на статус, а й на тіло відповіді. Саме в JSON часто є текст помилки, якого не видно з одного HTTP-коду.

Чому HTTP 200 ще не гарантує появу замовлення в CRM

Успішний HTTP-запит ще не означає, що CRM справді створила замовлення. Деякі API повертають 200, але всередині JSON передають status: error, message з описом проблеми або внутрішній код невдалої операції.

Інший варіант - асинхронна обробка. API приймає запит, повертає task_id, а саме замовлення створюється пізніше окремим процесом. У такому сценарії 200 OK підтверджує лише прийняття запиту, а не завершення всієї операції.

Після 200 OK варто знайти в тілі відповіді ознаку фактичного успіху: success, status, order_id, entity_id або інший ідентифікатор створеного запису. Якщо повернувся лише task_id, подивіться статус цього завдання. Якщо CRM має власний API-журнал, зіставте request ID із внутрішнім записом.

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

Інтеграція працює, але окремі замовлення зникають

Якщо більшість замовлень доходять до CRM, а губляться лише окремі, насамперед треба шукати періодичний збій, а не постійну помилку налаштування. API-key, endpoint і базова схема інтеграції вже працюють для інших замовлень, тому неправильний ключ не варто перевіряти першим.

Timeout і короткочасна недоступність API

Типові ознаки періодичного збою - timeout, connection reset, DNS failure, 502, 503 або різке збільшення часу відповіді. Запит міг потрапити в невдалий момент, коли CRM була перевантажена або мережеве з'єднання коротко перервалося. Такі збої незручні саме тим, що інтеграція начебто працює.

Rate limit і надто часті запити

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

Чому періодичний збій важче знайти

Для кількох невдалих замовлень зберіть точний час, order ID, код відповіді, тривалість запиту, кількість повторних спроб і стан черги. Потім зіставте ці дані з успішними замовленнями. Корисні показники - час відповіді, кількість timeout, кількість відповідей 429, failed jobs, довжина черги, помилки пам'яті та час виконання.

Найнебезпечніша ситуація - тиха помилка

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

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

Нормальна обробка помилки має залишити слід, з яким можна працювати: статус невдалої синхронізації, last error, last attempt, retry count і можливість ручної повторної відправки. Після кількох невдалих спроб адміністратор або відповідальний співробітник має отримати повідомлення.

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

Що зафіксувати до звернення до розробника або підтримки

• ID замовлення і точний час створення;

• статус замовлення на сайті;

• чи була спроба синхронізації;

• HTTP-код і текст відповіді CRM;

• останню помилку та кількість повторних спроб;

• чи є інші замовлення з таким самим симптомом;

• чи були перед цим оновлення, перенесення або зміни API.

Один конкретний order ID корисніший за опис "десь учора пропало кілька замовлень".

Повторна відправка потрібна, але може створити дублікати

Автоматичний retry без захисту від повторного створення може перетворити пропущені замовлення на дублікати. Особливо небезпечний сценарій, коли CRM встигла створити запис, але сайт не отримав відповідь через timeout.

Що відбувається, коли відповідь CRM не дійшла до сайту

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

External ID та idempotency без складної теорії

Повторне виконання тієї самої операції не повинно створювати ще одне замовлення, якщо перше вже існує. Для цього інтеграція може використовувати external_order_id, номер замовлення, unique integration ID або idempotency key, якщо CRM підтримує такий механізм.

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

Не можна сліпо повторювати запит, якщо невідомо, чи перша операція вже виконалась.

Коли причину потрібно шукати на сервері сайту

Працюючий сайт не доводить, що серверна частина інтеграції з CRM працює без помилок. Фронтенд відкривається - ще не означає, що фонові завдання виконуються. Окремий cron, worker або PHP-процес може вже не працювати, хоча покупець цього не помітить.

Cron, workers і черга

На сервері варто дивитися PHP error log, cron log, queue log, помилки memory_limit, max_execution_time, process limit, навантаження і час відповіді бази даних. Окремо перевіряють DNS resolution, можливість встановити HTTPS-з'єднання з API CRM, правила firewall та вихідні з'єднання.

Якщо інтеграція залежить від фонових процесів, cron-завдань або черги, значення має і середовище, в якому працює сайт. За нестабільної роботи PHP-процесів, дефіциту ресурсів або регулярних timeout обмін із CRM може перериватися навіть тоді, коли сам сайт зовні продовжує працювати. Для таких проєктів одним із варіантів може бути хмарний хостинг UkrLine, але перед перенесенням варто спочатку переконатися, що причина збою справді пов'язана із серверною частиною.

Що перевірити після перенесення сайту

Якщо синхронізація зникла саме після міграції, перевірка має бути предметною. Чи перенесено API-token та ENV-змінні? Чи працює cron? Чи не змінилася IP-адреса, яку CRM очікує у whitelist? Чи не залишився callback або webhook URL зі старим доменом? Чи дозволяє firewall вихідні запити до API?

Підозрювати сервер є сенс тоді, коли це підтверджують логи: missed cron, failed worker, timeout, memory error або заблоковане вихідне з'єднання. Міняти інфраструктуру "про всяк випадок" без такого підтвердження немає сенсу.

Як перевірити інтеграцію до того, як загубиться реальне замовлення

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

Одне контрольне замовлення від сайту до CRM

1. Створити тестове замовлення і зафіксувати order ID та точний час.

2. Переконатися, що замовлення збережено в адмінпанелі сайту.

3. Знайти запуск інтеграційного завдання або webhook.

4. Перевірити request: endpoint, timestamp, order ID.

5. Перевірити response: HTTP status, body, ID запису в CRM.

6. Знайти замовлення в CRM.

7. Звірити товар, суму, покупця, оплату, доставку і статус.

8. Перевірити, чи є retry після тимчасової помилки.

9. Переконатися, що повтор не створює дубль.

10. Перевірити, чи адміністратор отримає alert після кількох невдалих спроб.

Що потрібно перевірити після оновлення або міграції

Після змін не варто обмежуватися тим, що головна сторінка магазину відкривається і тестовий платіж проходить. Інтеграція має пройти повний цикл: сайт → завдання → request → response → CRM ID. Якщо хоча б одна точка не простежується, у майбутньому буде складно зрозуміти, де саме загубилося реальне замовлення.

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