Форма на сайті чудово працює, поки всі ваші клієнти приходять через сайт і самі описують проблему словами. Але щойно бізнес виростає з простого лендінга — з'являється мобільний застосунок, бекенд, який сам «знає» про проблеми користувачів, внутрішні панелі для команди підтримки, — форми стає замало. Тоді на сцену виходить API підтримки: спосіб створювати й вести звернення програмно, з будь-якої вашої системи, без людини, що заповнює поля вручну.
Різниця не косметична. Форма чекає, поки клієнт сам прийде й опише проблему своїми словами, часто без важливих технічних деталей. API дозволяє вашій системі самій ініціювати звернення в момент, коли вона щось помітила, — і одразу докласти весь потрібний контекст.
Що дає API підтримки
API — це інтерфейс, через який ваш код може робити те саме, що людина робить руками в адмінці: створити тикет, додати повідомлення до існуючої розмови, змінити статус, отримати історію звернень клієнта. Різниця в тому, що це відбувається автоматично й у потрібний момент, без участі людини на вашому боці.
Практично це означає, що звернення підтримки перестає бути чимось, що починається лише з дії клієнта. Воно може початися з події у вашій системі: помилки при оплаті, вичерпаного ліміту, збою інтеграції. Клієнт іноді навіть не встигає поскаржитися — тикет із деталями вже чекає в інбоксі команди підтримки.
Другий важливий момент — узгодженість даних. Коли звернення створюються вручну через різні форми, легко втратити частину контексту: версію застосунку, план клієнта, код помилки. Коли їх створює ваш код через API, ці поля передаються завжди, за одним і тим самим шаблоном, без пропусків через людський фактор.
Коли форми на сайті вже мало
- Звернення з бекенда. Ваша система помітила збій у клієнта — платіж не пройшов, вебхук партнера впав, синхронізація зависла — і сама заводить тикет із деталями, не чекаючи, поки клієнт напише вам першим.
- Мобільний застосунок. Кнопка «Підтримка» в застосунку створює звернення через API, а не веде користувача на зовнішню сторінку з формою, яку треба заповнювати вручну.
- Внутрішні інструменти. Ваша адмінка чи CRM заводить звернення від імені клієнта, коли з ним уже спілкуються інші канали — телефоном, у чаті продажів, на зустрічі.
- Масові події. Стався збій сервісу або планове технічне обслуговування — треба сповістити групу клієнтів і зібрати їхні відповіді в керовані, окремі тикети, а не в один нескінченний тред.
- Скрипти й автоматизації. Періодична перевірка стану облікових записів клієнтів виявляє аномалію — і замість алерту в Slack, який хтось може пропустити, система заводить тикет із чітким власником і статусом.
У кожному з цих сценаріїв спільне одне: звернення народжується не тому, що клієнт зайшов на сторінку контактів, а тому, що ваша власна система вирішила, що людині варто допомогти.
Приклад: звернення з бекенда
Уявімо типову ситуацію. Ваш бекенд обробляє платежі й бачить, що картка клієнта відхилена вже третій раз поспіль. Замість того щоб чекати, поки клієнт сам напише «у мене не проходить оплата», код одразу створює звернення — приблизно так, ілюстративно:
POST /api/tickets
{
"customer_id": "usr_48213",
"subject": "Повторна помилка оплати",
"message": "Картка відхилена тричі підряд, код помилки 51",
"context": { "plan": "pro", "attempts": 3 }
}Оператор бачить у інбоксі готовий тикет із поясненням, що сталося, ще до того, як клієнт встиг написати перше повідомлення. AI-чернетка вже враховує ці деталі при підготовці відповіді.
Такий підхід змінює саму динаміку підтримки: замість того щоб реагувати постфактум, команда випереджає скаргу. Клієнт бачить повідомлення «ми вже в курсі й розбираємося» ще до того, як встиг роздратуватися й написати перше сердите звернення сам. Для бізнесу це різниця між «доганяти» і «випереджати».
Що врахувати при роботі з API
- Ідентифікація клієнта. Передавайте стабільний ідентифікатор (наприклад, внутрішній ID користувача чи email), щоб звернення з різних джерел — сайту, застосунку, бекенда — зв'язувалися з тією самою людиною, а не створювали дублікати профілю.
- Контекст. Що більше корисних даних ви передасте разом зі зверненням — план клієнта, версію застосунку, код чи текст помилки, — то якісніша й точніша буде відповідь оператора чи AI-чернетки.
- Безпека ключів. Тримайте API-ключі на сервері, а не у відкритому клієнтському коді: код мобільного застосунку чи фронтенду не повинен містити ключ, яким можна створювати чи читати чужі звернення.
- Ідемпотентність запитів. Якщо ваш код може повторити запит через мережевий збій, подбайте про те, щоб повторна спроба не створювала другий однаковий тикет — це особливо важливо для автоматичних сценаріїв без людини в циклі.
- Обмеження частоти. Масові події та автоматизації можуть генерувати багато звернень за короткий час — плануйте, як ваша система поводитиметься, якщо створення тикетів тимчасово обмежене.
Жоден із цих пунктів не є перешкодою — це просто речі, про які варто подумати заздалегідь, а не після того, як у продакшені зʼявилося сто дублікатів одного й того самого тикета. Здебільшого достатньо один раз продумати схему ідентифікації клієнта й формат контексту, а далі просто дотримуватися її в кожному місці коду, що звертається до API.
API і вебхуки працюють у парі
API дозволяє вам ініціювати дії, а вебхуки — дізнаватися про те, що сталося у відповідь. Разом це замкнений цикл: ви створили тикет через API, а коли клієнт або оператор відповів — ваша система дізналася про це вебхуком і зреагувала: оновила статус у власній базі, розблокувала функцію, надіслала сповіщення потрібній людині.
Без цього другого боку API залишається лише одностороннім каналом «написати, але не почути відповідь». Саме поєднання створення звернень через API та підписки на події через вебхуки дозволяє повністю автоматизувати цикл — від виявлення проблеми до її вирішення й закриття тикета. Про другу половину цього циклу — стаття про вебхуки.
Тикети залишаються однаковими незалежно від джерела
Важлива деталь: звернення, створене через API, у самій системі підтримки виглядає й поводиться так само, як звернення з чату чи Telegram. У нього є історія повідомлень, статус, теги, позначка джерела. Оператор, що відкриває тикет, не має думати «ага, це прийшло з коду, тож тут щось особливе» — інтерфейс і логіка роботи однакові.
Це особливо цінно, коли команда підтримки одночасно веде розмови з людьми через чат-віджет на сайті (детальніше — у статті про вбудований віджет) та обробляє автоматичні звернення з бекенда. Обидва потоки зливаються в один інбокс, і оператору не потрібно перемикатися між різними інструментами чи логіками роботи.
Як це працює в Duck Float
У Duck Float публічний API — це повноцінний третій канал поряд із Telegram-ботом і чат-віджетом на сайт. Звернення, створені через API з вашого бекенда, мобільного застосунку чи внутрішніх інструментів, потрапляють у той самий інбокс, стають тикетами з історією, статусами й тегами — так само, як звернення з інших каналів.
На такі тикети так само працюють AI-чернетки відповідей: модель бере опис вашого продукту, який заповнюється один раз у налаштуваннях, і історію конкретної розмови, після чого готує чернетку мовою клієнта прямо в полі відповіді. Оператор бачить її одразу й може прийняти клавішею Tab, відредагувати або написати власну відповідь — нічого не йде клієнту автоматично без погляду людини. Більше про принцип таких чернеток — у статті про AI-чернетки.
А вебхуки й журнал подій повідомляють вашу систему про кожну зміну в тикеті — нову відповідь, зміну статусу, новий тег, — щоб ваш бекенд міг реагувати без постійного опитування API. Про всі три канали разом — стаття про один інбокс.
На час бети Duck Float безкоштовний. Якщо у вас є питання про API, вебхуки чи про те, як усе це підключити до вашої системи, — напишіть нам через віджет на цьому сайті, ми відповімо особисто.