Де закінчується ваша автоматизація

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

Коли автоматизація ламається, першою версією майже завжди стає «баг в інтеграції», і компанія йде до підрядника. Частина цих поломок сталася по той бік межі, де ні у вас, ні у підрядника немає ані прав, ані видимості. З'ясувати, яка саме частина, дешевше до інциденту.

Чому успішна відповідь не означає виконану дію?

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

Нижче — те, що Auspex заміряв власними прогонами на порталі Uspacy у серпні 2026 року. Це не претензія до конкретного вендора: у Uspacy є повна публічна документація REST з OpenAPI-схемами, чим може похвалитися не кожна платформа. Просто ми його заміряли, і межа виглядає так:

• значення списку, передані всередині поля при створенні цього поля, портал відкидає — поле створюється порожнім, помилки немає, статус 201
• запис прав ролі замінює весь набір воронкових прав, а не доповнює його, тож збереження одного права стирає решту — і теж успішно
• при створенні задачі три статуси з п'яти приймаються з кодом 201 і мовчки перетворюються на «заплановану», причому підмінене значення приходить уже в тілі відповіді
• право, записане на системну воронку, повертає 200 і не зберігається: заготовка прав з'являється у сутності лише в момент створення її першої власної воронки
• у тілі помилки поле status дорівнює true — ознака успіху стоїть і тоді, коли операція не пройшла

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

Документація описує намір вендора, живий прогін — фактичну поведінку. Різницю між ними ви несете самі.

Що означає «повторних відправок немає»?

Вебхук — це автоматичний виклик, який платформа надсилає вашій системі, коли в неї щось сталося. Виглядає як гарантія: сталася подія — прилетів запит. Вендори, які пишуть про це прямо, кажуть протилежне, і Bitrix24 тут найпрямолінійніший. У розділі про події його документація перелічує два обмеження без жодних пом'якшень.

Load cannot be regulated. When mass data changes occur, you will receive many consecutive calls. If a thousand deals are changed simultaneously in Bitrix24, the handler will receive a thousand calls. No retries. If your server does not respond or returns an error, the Bitrix24 queue server will log the failure but will not resend the event.

— Bitrix24 REST API documentation, розділ Events

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

Bitrix24 у цьому не гірший за інших — він просто написав це вголос. Shopify формулює ще жорсткіше:

Your app shouldn't rely on receiving data from Shopify webhooks. Webhook delivery isn't always guaranteed, and your app can miss or mishandle events for other reasons, such as handler failures or downtime. For redundancy, use reconciliation jobs to periodically fetch data from Shopify so that your app stays consistent with Shopify's data.

— Shopify Developer Documentation, Build webhooks

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

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

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

Гірший випадок — коли звірити нічим. У Bitrix24 метод отримання постів живої стрічки не повертає адресатів публікації, тож перевірити через API, у яку робочу групу пішов пост, неможливо: тільки очима в порталі.

Який ліміт ви не можете порахувати?

Bitrix24 документує свої ліміти детально, і це добре: обмеження інтенсивності працює за принципом дірявого відра, лічильник спадає на 2 запити за секунду, поріг блокування — 50, на тарифі Enterprise відповідно 5 і 250, а перевищення дає 503 з кодом QUERY_LIMIT_EXCEEDED.

Ліміт рахується за IP-адресою джерела запиту, тому кілька застосунків на одному сервері діляться спільним бюджетом. Ваша друга інтеграція мовчки з'їдає квоту першої, і в логах першої це виглядатиме як випадкові збої платформи.

Поруч живе другий ліміт — на накопичений час виконання методу, з кодом OPERATION_TIME_LIMIT і 429 у відповідь. Його порогове значення для хмари в документації не наведено: там сказано лише, що воно задається конфігурацією, а число 420 секунд стосується коробкової версії, де обмеження за замовчуванням вимкнене. І там же зазначено, що один і той самий запит у різних порталах споживає різний обсяг цього ліміту, бо обробляє різну кількість записів, а отже ресурсомісткість запиту неможливо визначити лише на боці застосунку.

Ліміт, споживання якого не вимірюється з вашого боку, не можна закласти в архітектуру — його можна тільки не перевищувати навмання.

Uspacy влаштований протилежно. Ми прогнали на його порталі 152 виклики зі створенням і видаленням записів у різній кількості потоків: жоден не повернув 429, а пропускна здатність росла майже лінійно — один потік давав близько одного запису на секунду, чотири — 4,9, вісім — 8,1, далі крива вигиналася. Прочитати це як «лімітів немає» — найдорожча помилка з можливих. Заміряно поведінку одного порталу в один день, а в публічній документації Uspacy немає жодної згадки ані про ліміти й код 429, ані про повтори доставки, ані про ідемпотентність — гарантію, що повторно доставлена подія не створить другий запис. Ліміт, якого немає в документації, не має і зобов'язання лишатися відсутнім: його можна ввести без анонсу саме тому, що його ніколи не обіцяли.

Тому черга з експоненційним backoff потрібна навіть там, де 429 не приходив жодного разу. Вона коштує день роботи один раз і рятує від переписування конвеєра в той тиждень, коли ліміт з'явиться.

Чому поверхня змінюється без вашого релізу?

14 серпня 2026 року у робочого вебхука Bitrix24 на нашому порталі з'явилися три нові права доступу, яких раніше не було. Під їхню відсутність був побудований обхідний шлях: список робочих груп діставали через історію повідомлень. Обхід став непотрібним за одну ніч, і жодного нашого релізу того дня не відбувалося.

Розширення прав — приємна зміна. Механізм у неї той самий, що й у неприємної: поверхня, на яку спирається ваш код, змінилася ззовні, і ми дізналися про це, бо перевіряли, а не бо нас повідомили. За нашим підрахунком по публічному changelog Bitrix24 (зріз на початок вересня 2026), за перші вісім місяців року вийшло 355 задокументованих змін API у 91 випуску. Це вендорський темп, до якого ваш реліз-цикл не має жодного стосунку.

Наскільки далеко це може зайти, видно з розкиду попереджень, які різні платформи дали за останні роки. У лютому 2023-го Twitter оголосив про припинення безкоштовного доступу до API за сім днів до дати відключення, а в березні того ж року дав тридцять днів на міграцію з усіх старих тарифів. Reddit у червні 2023-го назвав ціну — 0,24 долара за тисячу викликів — приблизно за місяць до початку списань; автор клієнта Apollo публічно просив три місяці й не отримав їх. На іншому полюсі Shopify зобов'язується підтримувати кожну версію API щонайменше дванадцять місяців із перекриттям сусідніх версій не менш ніж дев'ять, а Salesforce попереджав про виведення старих версій близько чотирьох з половиною років і добровільно подовжив термін після консультацій зі спільнотою.

Різниця між сімома днями і чотирма роками — це не технічна характеристика, а те, що вендор про себе написав. Прочитати це можна до підписання договору, а не після.

Ліцензійна угода Bitrix24 залишає за платформою право обмежити доступ до порталу при надмірному навантаженні, а сторінка підтримки пояснює процедуру: при некритичному навантаженні першому адміністратору надішлють повідомлення з проханням звернутися в підтримку, і якщо він не відповість, джерело навантаження заблокують; при високому — заблокують одразу. Числового порога немає, строку попередження немає, порядку оскарження немає. Задокументовані ліміти показують мінімум; стелю вендор лишає за собою.

Хто ще стоїть у ланцюжку без договору з вами?

Останній вендор у ланцюжку — той, з яким у вас немає договору. Це мережа. В Іспанії провайдери блокують адреси по IP на час футбольних трансляцій, і разом із піратами лягають усі сусіди по edge-адресу: за підрахунками OONI, півмільйона доменів з двох тисяч адрес, а під удар потрапляють саме машинні виклики — вебхуки, платіжні callback, ingest. Наш власний продакшн-сервіс у серпні 2026-го кілька вечорів поспіль був недоступний з Іспанії саме через це, поки всі його метрики лишалися зеленими. Розбір цієї межі з цифрами й перевіркою на годину — окремою нотаткою, посилання нижче.

Що з цим робити, не переписуючи все?

Захист від межі — це чотири звички і один документ. Архітектурна реформа тут не потрібна.

• тримайте власний append-only журнал подій на своєму боці, незалежний від платформи — без нього питання «скільки ми втратили» просто не має відповіді
• поставте періодичну звірку поруч із вебхуками: вебхук привозить подію за секунди, звірка добирає те, що не доїхало
• перечитування після запису там, де запис має ціну: порівнюйте з наміром, а не з кодом відповіді
• черга з backoff за замовчуванням, навіть коли ліміт ніде не задокументований

П'ятий пункт — це документ, і він найважливіший: список того, чого вендор вам не обіцяв. Гарантія доставки подій, політика повторів, ліміт запитів і спосіб його виміряти, вікно депрекації, порядок дій при блокуванні за навантаження — по кожному рядку напроти стоїть або посилання на документацію, або слово «ні». Усе, напроти чого стоїть «ні», ви страхуєте самі або свідомо не страхуєте. Третього варіанту немає — є тільки нез'ясований.

Де ця порада перестає працювати?

Найпоширеніша надмірна реакція — шар абстракції «щоб потім легко змінити CRM». Він подорожчує кожну фічу сьогодні заради події, дата й імовірність якої невідомі, і на практиці описує саме ту платформу, з якої його писали.

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

Пропорція проста. Захист має коштувати менше за очікувані збитки: для процесу на двадцять заявок на місяць власний журнал подій — надмір, для конвеєра, через який ідуть усі вхідні дзвінки, — мінімум.

Три перевірки, з яких варто починати

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

Якщо третій пункт дасть розбіжність, решту можна не робити: тиха втрата вже є і накопичується весь час, поки її ніхто не рахує.

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

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