Інтеграція під ключ, коли готового модуля під чужий API немає
Готовий модуль закриває популярні напрямки: перевізник, платіжний шлюз, знайома CRM. Далі починається зона, де конектора під вашу пару систем не існує, і обмін доводиться писати.
Кошторис тут визначає чужий бік, а не наш. Чи є в нього тестовий контур, чи повідомляє він про зміни вебхуком, чи має запис ідентифікатор, за яким його впізнають удруге, і чи відрізняє він відмову від успіху. Той самий обмін на підготовленому інтерфейсі займає тиждень, а на інтерфейсі, який на будь-що відповідає кодом 200 і порожнім тілом, — утричі більше.
Тому починаємо не з коду, а з розвідки: смикаємо методи й дивимося, що інтерфейс уміє насправді. Строк робіт після неї — 7–17 робочих днів. Вартість називаємо, коли побачимо чужий API, а не з опису задачі.
звірка кількості записів на двох боках двома методами
Приймання роботи
Як проходить робота
Прозорі етапи з погодженням на кожному кроці
Загальний строк:7–17 днів
1
Розвідка чужого інтерфейсу
2–5 робочих днів, безкоштовно
Смикаємо методи й перевіряємо вісім пунктів: документація, авторизація, вебхуки, ліміти, пагінація, ідентифікатор, поведінка при помилці, версіонування. На виході — письмовий висновок і чернетка контракту обміну.
2
Контракт обміну
1–3 робочих дні
Фіксуємо письмово: які записи передаються, у який бік, з якою частотою, за яким ідентифікатором і що вважається успіхом. Саме цей документ потім закриває суперечку про межі роботи.
3
Прототип на тестовому контурі
2–5 робочих днів
Перший робочий обмін в один бік і на одному типі записів. Якщо контуру в чужого сервісу немає, піднімаємо заглушку з відповідями за документацією й окремо перевіряємо її на живих даних пізніше.
4
Поведінка при збоях
2–4 робочих дні
Черга з повторними спробами, ідемпотентний ключ, журнал із тілом запиту й відповіді, маскування персональних даних, сповіщення відповідальному. Тут же навмисно ламаємо чужий бік і дивимося, чи не з'явився дубль.
5
Звірка на живих даних
1–3 робочих дні
Рахуємо записи на джерелі й на приймачі двома незалежними методами, пояснюємо кожну розбіжність. Прогон іде в режимі, який рахує зміни, але нічого не записує, — так помилка ідентифікатора вилазить до першого запису.
6
Запуск і передача
1–2 робочих дні
Переводимо обмін на бойові ключі, вмикаємо розклад і сповіщення, проходимо журнал із вашою людиною, віддаємо репозиторій та інструкцію.
Технології та інтеграції
На чому будуємо і з чим це з’єднується
Стек
REST з JSON — беремо той формат, який віддає чужий бік, а не зручніший нам
XML і CSV — коли сервіс живе на вивантаженнях, а не на запитах
Вебхуки з перевіркою підпису; межа: у частини сервісів їх немає взагалі
Опитування за розкладом через cron; межа: між циклами завжди є вікно розходження
Ідемпотентний ключ на операцію — захист від дублів при повторі
Черга з повторними спробами й наростаючим відступом
Журнал обміну в окремій таблиці з маскуванням персональних даних
Тестовий контур чужої системи, а за його відсутності — локальна заглушка
OpenCart 3 і 4, WooCommerce, Next.js на боці сайту
PHP, MySQL, Node.js
Git — репозиторій ваш
Інтеграції
довільний REST-API з документацією
вебхуки вхідні та вихідні
облікові системи 1С і BAS
KeyCRM та інші CRM за API
складські й ERP-системи
платіжні шлюзи
API перевізників
маркетплейси та прайс-агрегатори
поштові й SMS-сервіси
Telegram-бот для сповіщень
GA4 та Google Tag Manager
Що входить
Повний перелік робіт і того, що ви отримуєте на виході
Контракт обміну окремим документом: які записи, у який бік, з якою частотою і за яким ідентифікатором — за ним потім приймається робота
Обмін на тому механізмі, який реально є в чужого сервісу: вебхуки з перевіркою підпису там, де вони є, опитування за розкладом там, де їх немає
Ідемпотентний ключ на кожну операцію: повтор після збою оновлює наявний запис, а не створює другий
Черга з повторними спробами й наростаючим відступом — недоступність чужого боку відкладає передачу, а не втрачає її
Журнал обміну з тілом запиту й відповіді, персональні дані замасковані
Сповіщення відповідальному, коли черга не розібралася за узгоджений час
Звірка на живих даних двома незалежними методами до передачі роботи
Інструкція вашій людині: де журнал, як перезапустити передачу руками, як відрізнити збій чужого боку
Вихідники в Git на вашому боці — інтеграцію може підхопити інший розробник
Гарантія 30 календарних днів на виконані роботи
Коли ця послуга не підходить
Що не входить у роботу — щоб не було сюрпризів на здачі
Ліцензії, тарифи й комісії чужого сервісу
Зміни на боці чужої системи: якщо методу в API немає, додати його може лише власник
Наведення ладу у ваших довідниках і злиття дублів — окремий обсяг робіт
Підтримка після гарантійного строку, включно з переробкою під нову версію чужого API
Хостинг і обчислювальні потужності під обмін
Кому підходить
Ситуації, у яких ця послуга дає результат
Ситуація 1 з 4
У маркеті модуля під вашу пару систем немає
Галузева програма обліку, вузький сервіс бронювання, внутрішня система замовника, самописний склад. Ринок розширень покриває масові напрямки, і чим специфічніша система, тим менше шансів знайти готове. Тут інтеграція пишеться під конкретний інтерфейс — і саме тому починається з його розвідки.
Розберемо вашу ситуацію на безкоштовному аудиті
Ситуація 2 з 4
Модуль є, але робить не те, що потрібно
Передає половину полів, не вміє в зворотний напрямок, створює новий запис замість оновлення наявного. Підганяти чуже розширення іноді дорожче, ніж написати обмін під свій контракт: у першому випадку ви правите чужу логіку наосліп, у другому — володієте нею.
Ситуація 3 з 4
Обмін уже є, але ніхто не знає, чи він працює
Дані десь розходяться, а журналу немає, тому розбір починається з припущень. Ми міряємо обидва боки й показуємо, де саме губиться запис. Часто виявляється, що передача мовчки падає роками — статус відповіді успішний, а тіло порожнє.
Ситуація 4 з 4
Каталог або замовлення живуть у кількох системах одразу
Сайт, склад, кабінет менеджера, майданчик. Кожна пара з них потребує домовленості про ідентифікатор і напрямок передачі. Наш кейс саме про це: платформа рерайту описів приймає каталоги з п'яти майданчиків у чотирьох форматах, і жодного готового конектора під таку суміш не існує.
Написати інтеграцію під ключ проти того, щоб чекати на модуль від вендора
Чим цей варіант відрізняється від «Очікування готового модуля»
Очікування готового модуляНаш підхід
Коли з'явитьсяневідомо: вашої пари систем може не бути в планах вендора взагалі7–17 робочих днів після розвідки, дата в договорі
Покриття сценаріюте, що автор модуля вважав типовим випадкомрівно ваші записи, поля й правила з контракту обміну
Поведінка при збої чужого бокуяк зроблено всередині — ззовні не видно до першого інцидентучерга з повторами, ідемпотентний ключ, журнал, сповіщення
Коли чужий API змінитьсячекаєте на оновлення й на те, що автор його випуститьправимо ми, поломку видно в журналі того ж дня
Володінняліцензія й залежність від автора модулявихідники ваші, репозиторій у вас
Грошіліцензія й абонплата, іноді нуль — якщо модуль безкоштовний і підходитьодноразова розробка, далі лише зміни на чужому боці
Безкоштовна розвідка чужого інтерфейсу
До кошторису ми з'ясовуємо одну річ: чи готовий чужий бік до обміну взагалі. Частина запитів упирається не в код, а в те, що потрібного інтерфейсу в сервісу просто немає — і дізнатися це до оплати вигідніше для обох.
Що міряємо
Чи є документація і чи збігається вона з поведінкоюМи не читаємо опис, ми смикаємо кілька методів і звіряємо відповідь із обіцяним. Розходження тут — норма, і саме воно з'їдає дні на етапі розробки, якщо його не знайти заздалегідь.
Спосіб авторизаціїПостійний токен, OAuth чи лише сесія в браузері. Останнє означає, що публічного інтерфейсу немає: лишається імітувати роботу людини в кабінеті, і про крихкість такого рішення ми кажемо до договору.
Вебхуки чи опитуванняЯкщо сервіс сам повідомляє про зміни — обмін іде майже миттєво. Якщо ні, ми опитуємо його за розкладом, і між циклами лишається вікно, у яке два боки бачать різне. Розмір вікна називаємо числом до старту.
Ліміти запитів і пагінаціяСкільки звернень на хвилину дозволено і як віддається довгий список. Каталог на кілька тисяч позицій за жорсткого ліміту вивантажується не за хвилини, і це впливає на розклад обміну, а не лише на кошторис.
Стабільний ідентифікатор записуЗа яким значенням чужа система впізнає той самий товар або замовлення вдруге. Без нього повторна передача плодить дублі, і помітно це стає, коли їх уже сотні.
Що приходить у відповідь на помилкуПридатний інтерфейс відрізняє відмову від успіху. Непридатний віддає код 200 із порожнім тілом, і зовні це виглядає як успішна передача. У магазині косметики, який ми міряли 31.07.2026, штатний фід і карта сайту віддавали рівно це — 200 і нуль байтів.
Тестовий контурЧи можна ганяти обмін, не чіпаючи бойові дані. Якщо контуру немає, ми піднімаємо заглушку на своєму боці — це дорожче, і рядок з'являється в кошторисі відкрито.
Версіонування й попередження про зміниЧи має інтерфейс версії і чи повідомляє власник про зміни заздалегідь. Сервіс, який міняє формат мовчки, робить інтеграцію постійною витратою — і знати це треба до старту.
Що ви отримуєте на руки
Письмовий висновок по восьми пунктах розвідки: що інтерфейс уміє, чого не вміє й де в ньому дірки.
Чернетку контракту обміну: які записи, у який бік, з якою частотою і за яким ідентифікатором.
Оцінку робіт зі строком і переліком того, що може випасти з кошторису.
Розмову на 40 хвилин по документу — з вашим розробником, якщо він у вас є.
Строк: 2–5 робочих днів
Чому це безкоштовно
Бо найдорожча помилка тут — почати розробку під інтерфейс, який до обміну не готовий. Кілька днів розвідки дешевші за тиждень роботи, яку доведеться викинути.
Що далі
Після розвідки — сума, строк, договір. Якщо інтеграція під вашу задачу неможлива або не окупається, ви почуєте це першим листом, і рахунку не буде.
Форма коротка: контакт і адреса сайту
Не знайшли свій випадок?
Опишіть, як це влаштовано у вас, — відповімо, чи підходить «Інтеграція під ключ: чужий API, обмін даними, вебхуки» і що це означає у вашій ситуації. Без брифу й без дзвінка: одне питання, одна відповідь.
Працюємо офіційно
Договір, акт і рахунок — на кожен проєкт, а не тільки на великий. Без документів у вас немає ні прав на роботу, ні підстави провести витрати.
Договір, акт і гарантія 30 днів
На кожен проєкт письмовий договір: обсяг, строки, сума, порядок приймання. Після здачі — акт і рахунок, а далі 30 календарних днів гарантії: помилки з нашої вини усуваємо безоплатно. Усне з дзвінка дублюємо письмово того ж дня — домовленість, якої немає в тексті, не рахується.
ФОП і безготівковий розрахунок
Виконавець — зареєстрований ФОП. Оплата на рахунок із закривними документами, які бухгалтерія проведе як витрати. Курс для гривневої оплати фіксується договором, а не з’ясовується постфактум.
Права й доступи — ваші
Код, дизайн і матеріали переходять до вас після повної оплати. Домен, хостинг, репозиторій, аналітику й рекламні кабінети оформлюємо на вас — щоб сайт не залежав від підрядника. NDA підписуємо на запит, після завершення свої доступи видаляємо самі.
Портал клієнта замість переписки
На час роботи ви отримуєте доступ до порталу: договори, рахунки, акти й стан проєкту в одному місці. Документи формуються з даних угоди, тому реквізити й суми в них не розходяться, а про оплати й дедлайни нагадує система, а не пам’ять менеджера.
Замовники з Європи
Серед робіт — проєкти для Норвегії, Болгарії та Іспанії: болгарський магазин трьома мовами з кур’єрською доставкою, іспанський з оплатою карткою й переказом, норвезький сайт клініки. Це видно в портфоліо, а не тільки в описі.
Цифри, які можна перевірити
Кожен кейс у портфоліо — з посиланням на живий сайт і технічним виміром: швидкість відповіді, вага сторінки, обсяг каталогу, знайдені дефекти. Ці цифри можна зняти самому й звірити з нашими.
Спершу аудит, потім сума
Прайсу на сайті немає навмисно: обсяг тієї самої роботи у двох клієнтів відрізняється в рази, і цифра «від» нічого не пояснює. Спершу безкоштовний розбір — рахуємо ваші сторінки, дублі й швидкість, — потім називаємо суму й строк і фіксуємо їх у договорі.
Кажемо «ні», коли не впевнені
Якщо задача не наша, строк нереальний або послуга вам просто не потрібна — скажемо це першим листом, а не після передоплати. Гарантій позицій у пошуку не даємо: їх не дає ніхто, а обіцянка без механізму — це продаж, а не робота.
NDA підписуємо на запит. Після завершення співпраці наші доступи до ваших сервісів видаляємо самі й повідомляємо про це.
Що впливає на вартість
Чому дві однакові на вигляд задачі рахуються по-різному — і що саме ми міряємо на аудиті
Готовність чужого бокуГоловна складова кошторису, і залежить вона не від нас. Документований інтерфейс із тестовим контуром і вебхуками — нижня межа. Інтерфейс без опису, без контуру й без версій — верхня, бо формат доводиться відновлювати з мережевих запитів кабінету й перевіряти на заглушці.
Кількість типів записівПередавати лише замовлення — одна робота. Товари, залишки, ціни, статуси й повернення — п'ять окремих домовленостей про поля й ідентифікатор, кожну з яких треба звірити.
Напрямок обмінуОдин потік дешевший за два приблизно вдвічі. У зворотному напрямку додається конфлікт: якщо запис змінили з обох боків одночасно, хтось має вирішити, чия версія головна, і це рішення ваше, а не наше.
Обсяг і частотаСотня операцій на добу проходить будь-яким способом. Десятки тисяч позицій щогодини впираються в ліміти чужого сервісу, і тоді з'являється пагінація, батчі й розклад — окремий рядок робіт.
Стан ваших данихЯкщо спільного ідентифікатора між системами немає, обмін починається зі зіставлення довідників руками. Ця робота не входить у розробку й оцінюється окремо.
Вимоги до відмовостійкостіЧерга, повтори, журнал і сповіщення — це приблизно чверть трудомісткості. Відмовитися від них можна, але тоді перший же збій чужого боку означає тиху втрату даних.
Кейси
Задачі та результат у цифрах — усі показники зняті нашим виміром
власна SaaS-платформа рерайту описів товарів, приймає каталоги з п'яти майданчиків
Задача
Приймати вивантаження каталогів із Prom.ua, Rozetka, Хорошоп, OpenCart і WooCommerce у форматах XML, YML, CSV та Excel — готового конектора під таку суміш немає, кожен майданчик віддає своє.
Рішення
Застосунок на Next.js із власним розбором чотирьох форматів, налаштуванням стилю текстів і SEO-структурою заголовків. Оплата — безготівковий переказ на IBAN ФОП, мінімальне поповнення 50 грн. Розмітка JSON-LD із SoftwareApplication, Offer, Organization, WebSite і FAQPage, підключений PWA-маніфест.
Результат
Вимір 31.07.2026: перша відповідь 220,6 мс, повне завантаження 329,8 мс — найшвидший відгук серед 16 виміряних сайтів портфоліо, HTML 140,8 КБ, 8 публічних сторінок. Межу атрибуції називаємо прямо: сам імпорт каталогів ззовні не верифікується, ми міряли те, що видно з боку відвідувача. Той самий вимір дав два дефекти: robots.txt оголошує /sitemap.xml, який віддає 404, і на лендингу немає жодного лічильника аналітики.
інтернет-магазин професійної косметики, каталог понад 5 тис. позицій
Задача
Порахувати живий каталог там, де штатні джерела даних магазину не віддають нічого.
Рішення
Рахували штатним пошуком платформи з порожнім запитом посторінково, бо /sitemap.xml і товарний фід платформи відповідають кодом 200 із нульовим тілом.
Результат
5 561 товар — 55 сторінок по 100 позицій плюс 61 на останній, вимір 31.07.2026. Перша відповідь 801,2 мс при 153,8 КБ розмітки. Для інтеграції головне тут інше: два штатні джерела даних віддають успішний код і порожнє тіло, тобто статус відповіді не є доказом того, що дані приїхали. Той самий вимір показав, що лічильника аналітики на головній немає жодного.
оптовий B2B-каталог товарів із Китаю, майже 6 тис. позицій
Задача
Звірити реальний обсяг каталогу двома незалежними джерелами, перш ніж будувати на ньому вивантаження.
Рішення
Рахували двома способами: штатним пошуком платформи посторінково і за картами сайту обох мовних версій.
Результат
5 830 товарів: пошук дав 58 сторінок по 100 позицій плюс 30, карти сайту — по 6 234 адреси на кожну з двох мов, разом 12 468. Перша відповідь 506,9 мс при 333,1 КБ розмітки, вимір 31.07.2026. Різницю між 5 830 позиціями каталогу і 6 234 адресами карти сайту треба розібрати до запуску обміну, а не після першої розбіжності в залишках.
Що потрібно від вас
Без цього не почнемо — краще підготувати заздалегідь
1Документацію чужого API або доступ до кабінету, з якого її видно.
2Ключ до тестового контуру — саме тестового: бойові дані на етапі розробки нам не потрібні.
3Контакт технічної людини на боці чужого сервісу з правом відповісти про ліміти й формат.
4Перелік записів і полів, які справді потрібні: «усе, що є» перетворює обмін на постійну витрату.
5Правило ідентифікації: за яким значенням запис упізнається вдруге.
6Одну людину з вашого боку з правом погодити контракт обміну і прийняти роботу.
Якщо чогось із цього немає — скажіть, підкажемо, як зібрати або зробимо самі окремою задачею.
Часті питання
Те, що питають найчастіше — з конкретними відповідями
як зрозуміти, що з нашим сервісом інтеграція взагалі можлива?
Відповідає на це не опис на сайті вендора, а сам інтерфейс. Ми смикаємо кілька методів і дивимося на вісім речей: документація, авторизація, вебхуки, ліміти, пагінація, ідентифікатор запису, поведінка при помилці, версіонування. Найчастіший стоп-сигнал — авторизація лише сесією браузера: публічного інтерфейсу немає, і технічно лишається імітувати роботу людини в кабінеті. Ми таке робимо, але кажемо прямо, що рішення крихке й ламається від зміни верстки кабінету.
документації немає взагалі — це вирок?
Ні, але це інший обсяг робіт і інший ризик. Коли опису немає, формат відновлюється з мережевих запитів кабінету: видно адреси, склад полів і вигляд відповіді. Прочитати це нескладно. Проблема глибша: ніхто не зобов'язаний тримати такий інтерфейс незмінним, і власник може переробити його завтра, нікого не попередивши. Ми пишемо цей ризик у договір окремим рядком, щоб ви ухвалювали рішення до першої поломки, а не після неї.
чому успішна відповідь не означає, що дані передані?
Бо код відповіді описує транспорт, а не результат. Придатний інтерфейс відрізняє відмову від успіху й пояснює, що саме не так. Непридатний віддає 200 і порожнє тіло на будь-що. Це не теорія: у магазині професійної косметики, який ми міряли 31.07.2026, штатна карта сайту й товарний фід платформи відповідали кодом 200 із нульовим тілом — обидва джерела формально працювали. Тому успіхом ми вважаємо розібрану відповідь з очікуваними полями, а не сам факт з'єднання.
вебхуки чи опитування за розкладом?
Вебхуки, коли вони є: чужа система сама повідомляє про зміну, дані розходяться на секунди. У великої частини сервісів їх немає, і тоді лишається опитування раз на визначений проміжок. Головне тут не механізм, а названа цифра: між циклами є вікно, у яке два боки бачать різне. Для залишків це означає, що товар можуть купити двічі. Розмір вікна узгоджуємо до старту й пишемо в контракт обміну, замість слова «миттєвий».
що буде, коли чужий сервіс лежить?
Операція не має зникнути — вимога, від якої ми не відступаємо. Передача стає в чергу й повторюється з наростаючим відступом, поки не пройде. Щоб повтори не наплодили дублів, кожна операція несе ідемпотентний ключ: чужа система впізнає її як ту саму й оновлює наявний запис. Якщо черга не розібралася за узгоджений час, відповідальний отримує сповіщення. Без цих трьох речей збій на чужому боці стає тихою втратою даних, яку помічають за тижні.
як перевірити, що обмін працює правильно, а не просто працює?
Звіркою двома незалежними методами, і робимо ми її до передачі роботи, а не після скарги. Приклад із виміру 31.07.2026: в оптовому B2B-каталозі товарів із Китаю обсяг рахували двічі — штатний пошук платформи дав 58 сторінок по 100 позицій плюс 30, тобто 5 830 товарів, а карти сайту двох мовних версій дали по 6 234 адреси, разом 12 468. Кожен спосіб рахує свою множину адрес, і зійтися вони не зобов'язані — зобов'язана бути пояснена різниця. Той самий порядок дій переносимо на приймання обміну: рахунок на джерелі, рахунок на приймачі, розбір розходження.
скільки триває робота і чому сума днів по етапах більша за строк?
7–17 робочих днів після розвідки; сама розвідка триває 2–5 днів, вона безкоштовна й у строк не входить. Нижня межа — один напрямок передачі й один тип запису на документованому API з тестовим контуром. Верхня — обмін у два боки з кількома типами записів і зворотними статусами. Етапи частково йдуть паралельно: чергу й журнал ми пишемо, поки чекаємо доступів або відповіді технічної людини на чужому боці.
інтеграція зламається, коли вони змінять свій API?
Колись — так, і планувати це чесніше, ніж обіцяти вічну роботу. Тому обмін пишеться так, щоб поломка була помітною: журнал показує, який саме метод почав відповідати інакше, а сповіщення приходить у день збою, а не в день, коли не зійшовся звіт. Гарантійні 30 днів покривають помилки з нашого боку. Зміни на чужому боці — нова робота з окремою оцінкою; сервіси з версіонуванням дають на неї час, сервіси без нього не дають.
чи є у вас кейс саме з нашим сервісом?
Найімовірніше ні, і вигадувати його ми не станемо: чужий обмін ззовні не перевіряється. Показуємо те, що справді виміряли. Найближче до задачі — власна платформа рерайту описів товарів: вона приймає каталоги з п'яти майданчиків у чотирьох форматах, готового конектора під таку суміш не існує. Межу називаємо відкрито: сам імпорт ззовні не верифікується, ми міряли видиме — 220,6 мс до першої відповіді при 140,8 КБ розмітки. Ваш інтерфейс розберемо так само конкретно, до кошторису.
код і ключі лишаються нашими?
Так. Репозиторій ваш, вихідники передаються разом із роботами й інструкцією: де журнал, як перезапустити передачу руками, як відрізнити збій чужого боку від свого. Ключі доступу оформлюються на вас, а не на підрядника, і лежать у змінних середовища, а не в коді. Інтеграція, яку може супроводжувати лише її автор, — це залежність, і продавати таке ми не хочемо.
Надішліть посилання на документацію чужого API — або скажіть, що її немає.
У відповідь — висновок по восьми пунктах розвідки, чернетка контракту обміну й оцінка робіт зі строком. Якщо інтерфейс до обміну не готовий, ви почуєте це першим листом.
Прайса на сайті немає навмисно: обсяг тієї самої роботи у двох клієнтів відрізняється в рази, і цифра «від» у такому разі нічого не пояснює. Спершу безкоштовний аудит — рахуємо ваші сторінки, дублі й швидкість, — потім називаємо суму й строк і фіксуємо їх у договорі.