Як налаштувати надсилання результатів аналітики через webhook у CallAIder

Опубліковано: 3 липня 2026 р. · Оновлено: 3 липня 2026 р.

Webhook у CallAIder дозволяє автоматично передавати результати аналітики діалогів у вашу зовнішню систему: CRM, BI-дашборд, helpdesk, внутрішній кабінет, систему контролю якості або будь-який інший сервіс, який може приймати HTTP-запити.

Це зручно, коли результат аналізу не має залишатися тільки в інтерфейсі CallAIder. Наприклад, ви можете автоматично створювати задачу для керівника, якщо дзвінок потребує уваги, оновлювати картку клієнта в CRM, відправляти оцінку якості в BI або зберігати повну історію перевірок у власному сховищі.

У цій інструкції розберемо:

де вмикається доставка результатів;
як налаштувати умови, щоб надсилати не всі діалоги, а тільки потрібні;
які параметри webhook потрібно заповнити;
який JSON отримає ваша система;
як перевіряти підпис запиту;
як уникнути дублювання при повторних спробах доставки;
як протестувати інтеграцію перед запуском.

Коли варто використовувати webhook

Webhook потрібен, якщо після аналізу діалогу у вас має автоматично запускатися дія в іншій системі.

Типові сценарії:

Сценарій	Що можна зробити через webhook
Контроль якості	Передавати проблемні дзвінки керівнику або в систему оцінки операторів.
CRM	Оновлювати картку клієнта, угоду або звернення після аналізу розмови.
Helpdesk	Створювати тикет, якщо клієнт незадоволений або задача не виконана.
BI та звітність	Збирати оцінки, поля аналізу, тривалість і статуси у власному сховищі.
Внутрішні процеси	Запускати автоматизації: повідомлення, перевірки, маршрутизацію, ескалації.

Головна перевага webhook у тому, що дані передаються автоматично після завершення аналізу. Команді не потрібно вручну експортувати таблиці або регулярно перевіряти нові результати.

Як працює доставка результатів

З погляду клієнта процес виглядає так:

Діалог потрапляє в CallAIder і проходить аналіз за правилом аналітики.
CallAIder перевіряє, чи увімкнено надсилання результатів для команди.
Якщо задані умови надсилання, система перевіряє, чи підходить результат під ці умови.
Якщо умови виконані або умов немає, CallAIder надсилає HTTP-запит на URL, який ви вказали в налаштуваннях webhook.
Ваша система приймає JSON, обробляє його і повертає HTTP-статус 2xx.

Webhook не блокує роботу аналітики. Результат аналізу зберігається в CallAIder, а запит у вашу систему надсилається окремо. Тому між завершенням аналізу і отриманням webhook може бути невелика затримка.

Що потрібно підготувати перед налаштуванням

Перед тим як вмикати webhook у CallAIder, підготуйте endpoint у своїй системі.

Мінімальні вимоги:

публічний HTTPS URL, доступний для запитів ззовні;
підтримка JSON у тілі запиту;
швидка відповідь зі статусом 2xx, якщо payload прийнято;
обробка повторних запитів без створення дублікатів;
логування отриманих запитів на етапі тестування.

Також заздалегідь вирішіть, які саме результати потрібно передавати:

усі результати аналізу команди;
тільки діалоги з низьким балом;
тільки результати, які потребують уваги;
тільки діалоги, де конкретне поле аналізу має певне значення;
тільки дзвінки з потрібним напрямком, тривалістю, оператором або іншими даними діалогу.

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

Де налаштовується доставка

Налаштування доставки знаходяться у майстрі створення або редагування команди, на кроці Доставка.

На цьому кроці є три основні блоки:

Блок	Для чого потрібен
Умови надсилання	Визначають, які результати аналізу потрібно передавати у зовнішню систему.
Webhook	Налаштовує HTTP-запит: URL, метод, підпис, кількість спроб, заголовки та склад payload.
Email та Telegram	Майбутні канали доставки. Зараз вони відображаються в інтерфейсі, але не виконують надсилання.

Щоб webhook працював, потрібно увімкнути загальне надсилання результатів у верхній частині кроку Доставка і окремо увімкнути канал Webhook.

Крок Доставка в майстрі команди CallAIder

Крок 1. Увімкніть надсилання результатів

У верхній частині кроку Доставка увімкніть перемикач надсилання результатів.

Цей перемикач відповідає за доставку результатів для всієї команди. Якщо він вимкнений, webhook не надсилатиметься навіть тоді, коли в блоці Webhook заповнений URL.

Після цього переходьте до умов надсилання.

Крок 2. Налаштуйте умови надсилання

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

Якщо умови не задані, CallAIder надсилатиме всі успішні результати аналізу цієї команди.

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

Якщо ж webhook потрібен для реакції на конкретні ситуації, краще додати умови. Наприклад:

Потребує уваги = Так;
Загальний бал < 7;
Задача виконана = Ні;
Тривалість > 180;
Напрямок = incoming.

Режим перевірки умов

У блоці умов можна вибрати режим:

Режим	Як працює
Усі умови	Webhook буде надіслано тільки тоді, коли виконані всі додані умови.
Будь-яка умова	Webhook буде надіслано, якщо виконана хоча б одна з доданих умов.

Приклад для режиму Усі умови:

Потребує уваги = Так;
Загальний бал < 7.

У цьому випадку webhook буде надіслано тільки для результатів, які одночасно потребують уваги і мають загальний бал нижче 7.

Приклад для режиму Будь-яка умова:

Потребує уваги = Так;
Загальний бал < 7.

У цьому випадку webhook буде надіслано, якщо результат або потребує уваги, або має низький бал. Це ширша вибірка.

Джерела даних для умов

Умова складається з джерела даних, поля, оператора і значення.

Джерело	Що можна перевіряти	Приклад
Результат аналізу	Загальний бал, основний бал, штрафний бал, ознаку уваги, ліміт якості.	`Потребує уваги = Так`, `Загальний бал < 7`
Поле аналізу	Динамічні поля, які налаштовані у правилі аналітики.	`Задача виконана = Ні`, `Цільовий = Так`
Дані діалогу	Дані дзвінка або діалогу: тривалість, клієнт, оператор, напрямок тощо.	`Тривалість > 180`, `Напрямок = incoming`

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

Оператори умов

Доступні оператори залежать від типу поля, але в типових сценаріях використовуються такі:

Оператор	Приклад
Дорівнює	`Потребує уваги = Так`
Не дорівнює	`Задача виконана != Так`
Більше ніж	`Загальний бал > 8`
Більше або дорівнює	`Тривалість >= 60`
Менше ніж	`Загальний бал < 7`
Менше або дорівнює	`Штрафний бал <= 1`
Існує	`Email клієнта існує`
Не існує	`Email клієнта не існує`
Містить	`Назва клієнта містить "ТОВ"`

Крок 3. Увімкніть webhook

У блоці Webhook увімкніть перемикач Увімкнути webhook.

Після цього заповніть параметри HTTP-запиту.

Поле	Що вказати
URL	Endpoint у вашій системі, куди CallAIder надішле JSON.
Метод	HTTP-метод: `POST`, `PUT` або `PATCH`. Найчастіше використовується `POST`.
Секрет підпису	Необов’язковий секрет для перевірки, що запит справді надійшов від CallAIder.
Кількість спроб	Скільки разів CallAIder спробує надіслати webhook, якщо endpoint повернув помилку або не відповів.
Додавати поля аналізу	Додає у payload масив `data.result.fields` з динамічними полями правила аналітики.
Додавати діалог	Додає у payload `data.result.transcript` зі структурованою розшифровкою діалогу.
Додаткові заголовки	Дозволяє передати власні HTTP-заголовки, наприклад `Authorization`.

Рекомендований стартовий варіант:

метод: POST;
кількість спроб: 3;
секрет підпису: увімкнути, якщо endpoint приймає production-дані;
Додавати поля аналізу: увімкнути, якщо вам потрібні значення кастомних полів;
Додавати діалог: увімкнути тільки якщо зовнішній системі справді потрібна розшифровка.

Розшифровка діалогу може суттєво збільшити розмір payload. Якщо вам потрібні тільки оцінки, статуси та короткі поля аналізу, залиште Додавати діалог вимкненим.

Крок 4. Додайте заголовки авторизації

Якщо ваш endpoint захищений токеном, додайте його в блоці Додаткові заголовки.

Наприклад:

Authorization: Bearer <token>

Або, якщо у вашій системі прийнятий власний заголовок:

X-Api-Key: <api-key>

Не використовуйте додаткові заголовки для перевизначення службових заголовків CallAIder. Системні заголовки, такі як Content-Type, X-Callaider-Event, X-Callaider-Signature, X-Callaider-Delivery-Id та Idempotency-Key, формуються платформою.

Крок 5. Збережіть команду і виконайте тестовий аналіз

Після заповнення налаштувань збережіть команду.

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

На етапі тестування зручно використовувати тимчасовий endpoint на кшталт webhook.site. Так ви побачите:

чи приходить запит;
який метод використано;
які заголовки передані;
який JSON сформовано;
чи є підпис;
чи передаються додаткові заголовки.

Приклад отриманого webhook-запиту з результатом аналітики

Після перевірки замініть тестовий URL на production endpoint вашої системи.

Що вважається успішною доставкою

Webhook вважається доставленим, якщо ваш endpoint повернув HTTP-статус 2xx, наприклад:

200 OK;
201 Created;
202 Accepted;
204 No Content.

Якщо endpoint повернув 4xx, 5xx, не відповів або відповідь зайняла занадто багато часу, CallAIder може повторити надсилання відповідно до налаштованої кількості спроб.

Тому endpoint має бути готовий до повторних запитів. Це нормальна частина надійної доставки.

Як має поводитися ваш endpoint

Рекомендації для стабільної інтеграції:

Приймайте тіло запиту як JSON.
Перевіряйте авторизацію або підпис, якщо вони використовуються.
Зберігайте Idempotency-Key, щоб не створювати дублікати.
Повертайте 2xx, коли payload прийнято.
Важку обробку виконуйте асинхронно на своєму боці.
Логуйте eventId, resultId, data.analyzableItemId і X-Callaider-Delivery-Id для діагностики.
Не записуйте секрети, токени і повні персональні дані в відкриті логи.

Простий принцип: endpoint має швидко прийняти подію, підтвердити отримання і вже потім виконувати довші бізнес-процеси у вашій системі.

Службові заголовки webhook

CallAIder надсилає webhook із JSON-тілом і службовими заголовками.

Заголовок	Опис
`Content-Type`	Завжди `application/json`.
`X-Callaider-Event`	Тип події. Для результатів аналітики: `analytics.result.completed`.
`X-Callaider-Delivery-Id`	ID конкретної спроби доставки. Корисний для технічних логів.
`Idempotency-Key`	Стабільний ключ для захисту від дублювання при повторних запитах.
`X-Callaider-Signature`	HMAC-підпис тіла запиту. Передається тільки якщо задано секрет підпису.

Додаткові заголовки, які ви вказали в налаштуваннях webhook, також будуть передані у запиті.

Формат payload

Тіло запиту завжди надсилається у форматі JSON.

Загальна структура:

{
  "event": "analytics.result.completed",
  "timestamp": "2026-07-03T06:27:55.693Z",
  "eventId": "analytics-result-1678",
  "companyId": 1,
  "commandId": 1,
  "ruleItemId": 1,
  "resultId": 1678,
  "data": {
    "eventId": "analytics-result-1678",
    "occurredAt": "2026-07-03T03:27:54.832Z",
    "companyId": 1,
    "commandId": 1,
    "ruleItemId": 1,
    "taskId": 427,
    "analyzableItemId": 19668,
    "result": {},
    "item": {}
  }
}

Верхній рівень payload

Поле	Тип	Що означає
`event`	`string`	Тип події. Для цього webhook: `analytics.result.completed`.
`timestamp`	`string`	Час формування webhook-запиту.
`eventId`	`string`	ID події результату аналізу. Корисний для логування.
`companyId`	`number`	ID компанії у CallAIder.
`commandId`	`number \| null`	ID команди, до якої належить результат.
`ruleItemId`	`number \| null`	ID правила аналітики, за яким виконано аналіз.
`resultId`	`number`	ID конкретного результату аналізу.
`data`	`object`	Основні дані події: результат аналізу і дані діалогу.

Чим відрізняються ID діалогу і ID результату

Для інтеграції важливо не плутати діалог і результат аналізу.

Ідентифікатор	Що означає	Як використовувати
`data.analyzableItemId`	Основний ID діалогу або іншого об’єкта, який аналізувався.	Використовуйте як ID діалогу у своїй системі.
`data.item.id`	ID об’єкта у блоці з деталями діалогу.	Зазвичай збігається з `data.analyzableItemId`.
`resultId` / `data.result.id`	ID конкретного результату аналізу.	Використовуйте як ID окремої перевірки або версії аналізу.
`eventId`	ID події надсилання результату.	Корисний для логування і технічної дедуплікації подій.

Один і той самий діалог може бути проаналізований повторно. У такому випадку data.analyzableItemId залишиться тим самим, а resultId і data.result.id будуть іншими.

Рекомендована модель зберігання у вашій системі:

діалог зберігати або оновлювати за data.analyzableItemId;
результати аналізу зберігати окремими записами за data.result.id;
актуальний результат визначати за data.result.analyzedAt або власною бізнес-логікою.

Не використовуйте resultId як єдиний ID діалогу. Це ID результату аналізу, а не самого діалогу.

Блок `data.result`

data.result містить результат аналітики.

Поле	Тип	Що означає
`id`	`number`	ID конкретного результату аналізу.
`score`	`number \| string \| null`	Основний бал.
`penaltyScore`	`number \| string \| null`	Штрафний бал.
`totalScore`	`number \| string \| null`	Підсумковий бал.
`lessThanAcceptableLimit`	`boolean`	Чи нижчий результат за допустимий ліміт якості.
`attention`	`boolean`	Чи потребує результат уваги.
`scoringJustification`	`string \| null`	Пояснення нарахування балів.
`penaltyJustification`	`string \| null`	Пояснення штрафів.
`analyzedAt`	`string \| null`	Час завершення аналізу.
`fields`	`array`	Динамічні поля правила аналітики. Є тільки якщо увімкнено Додавати поля аналізу.
`transcript`	`array`	Структурована розшифровка діалогу. Є тільки якщо увімкнено Додавати діалог.

Блок `data.result.fields[]`

Масив fields містить поля, які налаштовані у правилі аналітики.

Приклад:

{
  "name": "Задача виконана",
  "value": "true",
  "fieldKey": "field_105",
  "fieldType": "boolean",
  "aiJustification": "Оператор успішно переніс запис клієнта на інший день та час."
}

Поле	Тип	Що означає
`name`	`string`	Назва поля, яку бачить користувач у CallAIder.
`value`	`string`	Значення, визначене аналітикою. Для boolean передається `"true"` або `"false"`.
`fieldKey`	`string \| null`	Стабільний технічний ключ поля. Його краще використовувати для мапінгу.
`fieldType`	`string`	Тип поля: наприклад `string`, `number`, `boolean`.
`aiJustification`	`string \| null`	Пояснення, чому аналітика визначила саме таке значення.

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

Блок `data.result.transcript[]`

Якщо увімкнено Додавати діалог, у payload буде структурована розшифровка.

Приклад:

{
  "text": "Добрий день, мене звати Артем...",
  "speaker": "operator",
  "timestamp": "00:00",
  "speakerName": "Оператор"
}

Поле	Тип	Що означає
`text`	`string`	Фраза з діалогу.
`speaker`	`string`	Роль учасника: наприклад `operator` або `client`.
`timestamp`	`string`	Час фрази у діалозі.
`speakerName`	`string \| null`	Ім’я учасника, якщо воно визначене.

Вмикайте передачу розшифровки тільки тоді, коли вона потрібна вашому сценарію. Для багатьох інтеграцій достатньо оцінок, полів аналізу і даних діалогу.

Блок `data.item`

data.item містить інформацію про дзвінок або інший об’єкт, який аналізувався.

Поле	Тип	Що означає
`id`	`number`	ID об’єкта у CallAIder. Зазвичай збігається з `data.analyzableItemId`.
`itemType`	`string`	Тип об’єкта, наприклад `CALL`.
`sourceType`	`string`	Джерело об’єкта, наприклад `integration_call`.
`contentType`	`string \| null`	Тип контенту, наприклад `audio`.
`commandId`	`number \| null`	ID команди.
`externalId`	`string \| null`	ID у зовнішній системі або провайдері.
`clientNumber`	`string \| null`	Номер клієнта.
`clientName`	`string \| null`	Ім’я клієнта.
`clientEmail`	`string \| null`	Email клієнта.
`operatorNumber`	`string \| null`	Номер оператора.
`operatorId`	`string \| null`	ID оператора у зовнішній системі.
`operatorName`	`string \| null`	Ім’я оператора.
`operatorEmail`	`string \| null`	Email оператора.
`direction`	`string \| null`	Напрямок дзвінка, наприклад `incoming` або `outgoing`.
`startTime`	`string \| null`	Час початку.
`endTime`	`string \| null`	Час завершення.
`duration`	`number \| null`	Тривалість у секундах.
`providerProperties`	`object \| null`	Додаткові дані провайдера або інтеграції.

Скорочений приклад payload

Нижче приклад webhook payload. Персональні дані в прикладі знеособлені.

{
  "event": "analytics.result.completed",
  "eventId": "analytics-result-1678",
  "resultId": 1678,
  "commandId": 1,
  "companyId": 1,
  "timestamp": "2026-07-03T06:27:55.693Z",
  "data": {
    "eventId": "analytics-result-1678",
    "occurredAt": "2026-07-03T03:27:54.832Z",
    "companyId": 1,
    "commandId": 1,
    "ruleItemId": 1,
    "taskId": 427,
    "analyzableItemId": 19668,
    "result": {
      "id": 1678,
      "score": 2.1,
      "totalScore": 2.1,
      "penaltyScore": 0,
      "attention": true,
      "lessThanAcceptableLimit": false,
      "analyzedAt": "2026-07-03T03:27:54.832Z",
      "scoringJustification": "Оператор виконав основні етапи розмови...",
      "penaltyJustification": "",
      "fields": [
        {
          "name": "Ім'я клієнта",
          "value": "Артем",
          "fieldKey": "field_488",
          "fieldType": "string",
          "aiJustification": "Клієнт представився на початку розмови."
        },
        {
          "name": "Задача виконана",
          "value": "true",
          "fieldKey": "field_105",
          "fieldType": "boolean",
          "aiJustification": "Оператор успішно переніс запис клієнта."
        }
      ],
      "transcript": [
        {
          "text": "Добрий день, мене звати Артем...",
          "speaker": "operator",
          "timestamp": "00:00",
          "speakerName": "Оператор"
        }
      ]
    },
    "item": {
      "id": 19668,
      "itemType": "CALL",
      "sourceType": "integration_call",
      "contentType": "audio",
      "commandId": 1,
      "externalId": "6693228761",
      "clientNumber": "050***8290",
      "clientName": "",
      "clientEmail": null,
      "operatorNumber": "722",
      "operatorId": "",
      "operatorName": "Оператор",
      "operatorEmail": null,
      "direction": "incoming",
      "startTime": "2026-07-03T06:22:52.000Z",
      "endTime": null,
      "duration": 83,
      "providerProperties": null
    }
  }
}

Перевірка підпису

Якщо в налаштуваннях webhook задано Секрет підпису, CallAIder додасть заголовок:

X-Callaider-Signature: sha256=<hex-hmac>

Підпис формується як HMAC-SHA256 від сирого тіла HTTP-запиту.

Це дозволяє вашій системі перевірити, що payload не був змінений і запит справді сформований з використанням секрету, який знаєте тільки ви і CallAIder.

Приклад перевірки на Node.js:

import crypto from 'crypto';

function verifyCallaiderSignature(
  rawBody: string,
  receivedSignature: string | undefined,
  secret: string,
): boolean {
  if (!receivedSignature) {
    return false;
  }

  const expectedSignature =
    'sha256=' +
    crypto.createHmac('sha256', secret).update(rawBody).digest('hex');

  const received = Buffer.from(receivedSignature);
  const expected = Buffer.from(expectedSignature);

  return (
    received.length === expected.length &&
    crypto.timingSafeEqual(received, expected)
  );
}

Важливо: для перевірки потрібно використовувати саме сире тіло HTTP-запиту. Не перевіряйте підпис по JSON-об’єкту, який уже був розпарсений і зібраний повторно, бо навіть незначна зміна форматування змінить HMAC.

Ідемпотентність і повторні спроби

Webhook може прийти повторно, якщо попередня спроба не була підтверджена успішною відповіддю. Наприклад, endpoint тимчасово повернув 500, запит завершився таймаутом або з’єднання обірвалося.

Щоб не створювати дублікати:

Зберігайте значення заголовка Idempotency-Key.
Якщо запит з таким ключем уже був успішно оброблений, не створюйте повторний запис.
Для повторного запиту, який не потребує нової обробки, повертайте 2xx.

Також можна логувати eventId, resultId і X-Callaider-Delivery-Id, але для захисту від дублювання конкретної доставки найкраще використовувати саме Idempotency-Key.

Окремо врахуйте повторний аналіз одного й того самого діалогу:

якщо потрібно оновлювати картку діалогу, шукайте її за data.analyzableItemId;
якщо потрібно зберігати історію аналізів, створюйте окремий запис для кожного data.result.id;
не використовуйте resultId як єдиний ідентифікатор діалогу.

Практичні сценарії налаштування

Надсилати всі результати аналізу команди

Використовуйте цей сценарій, якщо ваша система має отримувати повну копію результатів.

Налаштування:

загальне надсилання результатів увімкнено;
webhook увімкнено;
URL заповнений;
умови не задані;
за потреби увімкнено Додавати поля аналізу.

Результат: CallAIder надсилатиме всі успішні результати аналізу цієї команди.

Надсилати тільки проблемні дзвінки

Використовуйте цей сценарій для контролю якості, ескалацій і задач керівнику.

Налаштування:

режим умов: Будь-яка умова;
умова 1: Потребує уваги = Так;
умова 2: Загальний бал < 7.

Результат: webhook прийде для дзвінків, які потребують уваги або мають низький бал.

Надсилати тільки дзвінки, де задача не виконана

Використовуйте цей сценарій, якщо у правилі аналітики є поле, яке визначає результат розмови.

Налаштування:

джерело: Поле аналізу;
поле: Задача виконана;
оператор: Дорівнює;
значення: Ні.

Результат: webhook прийде тільки тоді, коли аналітика визначила, що задача не виконана.

Надсилати тільки довгі вхідні дзвінки з низьким балом

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

Налаштування:

режим умов: Усі умови;
умова 1: Напрямок = incoming;
умова 2: Тривалість > 180;
умова 3: Загальний бал < 7.

Результат: webhook прийде тільки для вхідних дзвінків довше трьох хвилин, у яких результат нижчий за потрібний рівень.

Типові помилки і як їх перевірити

Webhook не приходить

Перевірте:

чи увімкнено загальне надсилання результатів на кроці Доставка;
чи увімкнено перемикач Webhook;
чи правильно вказаний URL;
чи доступний endpoint ззовні;
чи результат аналізу справді відповідає умовам надсилання;
чи не повертає endpoint помилку або таймаут.

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

У payload немає полів аналізу

Перевірте, чи увімкнено опцію Додавати поля аналізу.

Також переконайтеся, що у правилі аналітики справді налаштовані динамічні поля, які мають потрапити в data.result.fields.

У payload немає розшифровки діалогу

Перевірте, чи увімкнено опцію Додавати діалог.

Якщо розшифровка не потрібна вашому процесу, краще залишити цю опцію вимкненою, щоб payload був компактнішим.

Endpoint повертає `401` або `403`

Перевірте:

чи додано потрібний Authorization або X-Api-Key;
чи немає зайвих пробілів у токені;
чи не очікує ваша система іншу назву заголовка;
чи не блокує запит firewall або reverse proxy.

Підпис не збігається

Найчастіші причини:

використовується не той секрет;
підпис перевіряється не по сирому тілу запиту;
middleware спочатку парсить JSON і змінює формат тіла;
у коді використано інше кодування або інший алгоритм.

Для HMAC потрібен саме raw body, отриманий до будь-якого перетворення.

У зовнішній системі з’являються дублікати

Перевірте, чи зберігаєте ви Idempotency-Key і чи не створюєте повторний запис для вже обробленого ключа.

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

діалог ідентифікується через data.analyzableItemId;
результат аналізу ідентифікується через data.result.id;
повторна доставка не створює дубль тієї самої події.

Поточні обмеження

Зараз реалізоване надсилання результатів через webhook.
Email та Telegram відображаються у формі як майбутні канали, але поки не виконують надсилання.
Надсилання відбувається асинхронно, тому webhook може прийти з невеликою затримкою після завершення аналізу.
Успішною доставкою вважається тільки відповідь вашого endpoint зі статусом 2xx.

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

Зв'яжіться з нами

Коли варто використовувати webhook

Як працює доставка результатів

Що потрібно підготувати перед налаштуванням

Де налаштовується доставка

Крок 1. Увімкніть надсилання результатів

Крок 2. Налаштуйте умови надсилання

Режим перевірки умов

Джерела даних для умов

Оператори умов

Крок 3. Увімкніть webhook

Крок 4. Додайте заголовки авторизації

Крок 5. Збережіть команду і виконайте тестовий аналіз

Що вважається успішною доставкою

Як має поводитися ваш endpoint

Службові заголовки webhook

Формат payload

Верхній рівень payload

Чим відрізняються ID діалогу і ID результату

Блок data.result

Блок data.result.fields[]

Блок data.result.transcript[]

Блок data.item

Скорочений приклад payload

Перевірка підпису

Ідемпотентність і повторні спроби

Практичні сценарії налаштування

Надсилати всі результати аналізу команди

Надсилати тільки проблемні дзвінки

Надсилати тільки дзвінки, де задача не виконана

Надсилати тільки довгі вхідні дзвінки з низьким балом

Типові помилки і як їх перевірити

Webhook не приходить

У payload немає полів аналізу

У payload немає розшифровки діалогу

Endpoint повертає 401 або 403

Підпис не збігається

У зовнішній системі з’являються дублікати

Рекомендований чекліст запуску

Поточні обмеження

Служба підтримки

Блок `data.result`

Блок `data.result.fields[]`

Блок `data.result.transcript[]`

Блок `data.item`

Endpoint повертає `401` або `403`