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

На схемі інтеграція виглядає як два прямокутники і стрілка між ними: ваша система і 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 у цьому не гірший за інших — він просто написав це вголос. 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 повторює доставку вісім разів протягом чотирьох годин — і після восьми поспіль невдалих спроб видаляє підписку, попередивши листом на технічну адресу застосунку. 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 залишає за платформою право обмежити доступ до порталу при надмірному навантаженні, а сторінка підтримки пояснює процедуру: при некритичному навантаженні першому адміністратору надішлють повідомлення з проханням звернутися в підтримку, і якщо він не відповість, джерело навантаження заблокують; при високому — заблокують одразу. Числового порога немає, строку попередження немає, порядку оскарження немає. Задокументовані ліміти показують мінімум; стелю вендор лишає за собою.

Де проходить межа вашої автоматизації — нижче за API?

Останній вендор у ланцюжку — той, з яким у вас немає договору. Це мережа.

З 18 грудня 2024 року в Іспанії діє рішення Комерційного суду №6 Барселони у справі, поданій LaLiga разом із Telefónica Audiovisual Digital: на час трансляцій матчів провайдери блокують IP-адреси, з яких ідуть піратські стріми. Блокують саме по IP, не по домену і не по SNI. Один edge-адрес Cloudflare обслуговує десятки тисяч чужих доменів, тому разом із піратами лягають усі сусіди. Спроби Cloudflare і RootedCON скасувати рішення суд відхилив 26 березня 2025 року, без права оскарження.

Масштаб порахували в OONI. З 9,2 мільйона доменів, просканованих з Іспанії з 1 січня по 1 червня 2026 року, 554 507 хоча б раз були недоступні. На Cloudflare припадає 501 305 із них — 90,4% усієї шкоди, і йде вона всього з 2 218 адрес. Щоб на одну годину покласти понад 400 тисяч доменів, достатньо вимкнути від чотирьох до двадцяти IP. Самі автори називають ці числа нижньою межею.

Для бізнесу наслідок не «клієнт не зайшов на сайт». Іспанська агенція WAM разом з Interactiv4 розібрала випадок, де під блок потрапили зворотні виклики платіжного шлюзу Redsys до магазинів на Adobe Commerce: платіж проходив, а сповіщення про нього не долітало, тому замовлення не позначалися оплаченими, рахунки не виставлялися, невдалі замовлення не скасовувалися. Після перенесення приймача сповіщень на піддомен поза Cloudflare частка провалених підтверджень впала з 48,88% до 1,62%. У списку заблокованого в OONI поруч із сайтами лежать s3.amazonaws.com і registry.terraform.io, а навесні 2026-го в Іспанії масово перестав працювати docker pull. Ламається саме machine-to-machine — той шар, у якому нема кому поскаржитися.

Перевірити власну експозицію можна однією командою. Запит dig +short auspex.company повертає 188.114.96.5 і 188.114.97.5 — рівно ту пару адрес, на якій наш власний продакшн-сервіс у серпні 2026-го кілька вечорів поспіль був недоступний з Іспанії, поки всі його метрики лишалися зеленими. Якщо у вас є клієнти в Іспанії, накладіть провали ingest за останні місяці на календар турніру: перевірка займає годину.

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

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

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

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

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

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

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

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

З чого почати цього тижня?

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

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

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

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